ruby on rails - RSpec 'Expect' Syntax and Idiomatic attribute spec -

this should have easy answer i'm struggling find (have checked rspec documentation, everydayrails testing rspec, google results). in model specs include basic attribute specs follows:

describe foo   describe "basic attributes"     before { @foo = create(:foo) }     subject { @foo }      { should be_valid }     { should respond_to(:color) }     { should respond_to(:height) }     { should respond_to(:some_other_attribute) }     { should respond_to(:you_get_the_idea) }     ... 

i these specs because if there kind of error within factory and/or model these specs me pinpoint quickly.

i've incorporated expect syntax other specs , how reads, how use here? 1 option might

expect(@foo).to respond_to(:color) 

and might be

expect(it).to respond_to(:color) 

the former involves duplication avoided should syntax, latter looks strange me (which me).

i realize question more style functionality*, ruby developers conscientious style, , want adhere standard practices , have readable, idiomatic code. appreciated. thanks.

update: neither of proposed options work, way. both throw undefined method 'expect' errors. i'm confused!

having thought error, realize it's because should specs above within one-line block. confusion, then, how can write single-line block expect syntax? in light of update, question functionality , i'll excited hear others' thoughts.

4/2015 update

rspec > 3.0 has added yet way of handling these, , sounds rspec ~> 4.0 away should syntax. per myron masters:

some users have expressed confusion how should relates expect syntax , if can continue using it. continue available in rspec 3 (again, regardless of syntax configuration), we've added alternate api bit more consistent expect syntax:

describe post   { is_expected.to allow_mass_assignment_of(:title) } end 

is_expected defined expect(subject) , supports negative expectations via is_expected.not_to matcher. [...]
in rspec 3, we've kept should syntax, , available default, deprecation warning if use without explicitly enabling it. pave way being disabled default (or potentially extracted seperate gem) in rspec 4, while minimizing confusion newcomers coming rspec via old tutorial.

myron marston, 1 of core rspec committers, explains here should still use

it { should be_cool } 

if you've disabled should syntax, offers solution alias expect_it it:

rspec.configure |c|   c.alias_example_to :expect_it end  rspec::core::memoizedhelpers.module_eval   alias should   alias to_not should_not end 

with in place, write as:

describe user   expect_it { be_valid } end