RSpec Pending Syntax and Identifier Attributes Specification

Question

This should have an easy answer, but I'm struggling to find it (checked the RSpec documentation, EverydayRails Testing with RSpec, Google results). In my model specifications, I would like to include basic attribute specifications as follows:

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

I like these specifications because if there is some kind of error in my factory model and / or some kind of error, these specifications help me quickly identify it.

I have included expect syntax in all other specifications, and I like the way it reads, but how to use it here? One option might be

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

And maybe still

 expect(it).to respond_to(:color) 

The former involves duplication, which should be avoided by the syntax, but the latter seems strange to me (it can only be me).

I understand that this issue is more about style than functionality *, but we, the Ruby developers, are honest about the style, and I want to adhere to standard practices and have readable, idiomatic code. Any help is appreciated. Thank.

UPDATE: By the way, none of my proposed options work. They both throw undefined method 'expect' errors. Now I'm really confused!

Thinking about the error, I understand this because the should specifications above are within the same line block. Then there is confusion, how can I write a one-line block with wait syntax? In the light of this update, the issue of functionality is very important, and I will be happy to hear the thoughts of others.

4/2015 UPDATE

rspec > 3.0 added another way to handle them, and it looks like rspec ~> 4.0 away with the should syntax. Per Miron Masters:

Some users have expressed confusion as to how this should relate to wait syntax, and if you can continue to use it. It will continue to be available in RSpec 3 (again, regardless of syntax configuration), but we also added an alternative API that is a bit consistent with the wait syntax:

 describe Post do it { is_expected.to allow_mass_assignment_of(:title) } end 

is_expected is defined very simply as an expectation (subject), and also supports negative expectations through an is_expected.not_to matcher. [...]
In RSpec 3, we have kept the if syntax, and it is available by default, but you will get a deprecation warning if you use it without explicitly enabling it. This will pave the way for disabling it by default (or potentially extracted into a separate stone) in RSpec 4, while minimizing the confusion for beginners arriving at RSpec through an old tutorial.

Answer 1

Myron Marston, one of the main RSpec committer, explains here that you should use anyway

 it { should be_cool } 

If you turned off the should syntax, it offers a solution for the expect_it alias - it :

 RSpec.configure do |c| c.alias_example_to :expect_it end RSpec::Core::MemoizedHelpers.module_eval do alias to should alias to_not should_not end 

In doing so, you can write this as:

 describe User do expect_it { to be_valid } end 

Answer 2

I don’t think there is a correct answer to this question, but I recently rewrote my test classes to move away from should and use expect syntax exclusively, so I will throw my two cents I decided to rewrite a lot, because Myron Marston , who accompanies RSpec, wrote :

In the future, we plan to change the default values ​​so that only the wait is available, unless you explicitly allow. We can do this as soon as RSpec 3.0, but we want to give users a lot of time to deal with it.

He also commented :

We do not plan to remove "should" ... but expect fewer errors, and this is the syntax I would recommend for new projects.

I agree with Mark Rushakoff's answer , but personally I do not want to create these aliases in order to preserve only one it -block syntax style. So, using your example, where I originally wrote a model model, for example, your example in this form:

 describe Foo do let(:foo) { create(:foo) } subject { foo } describe "model attributes" do it { should be_valid } it { should respond_to(:color) } it { should respond_to(:height) } it { should respond_to(:some_other_attribute) } it { should respond_to(:you_get_the_idea) } end # ... end 

Now I will write like this:

 describe Foo do let(:foo) { create(:foo) } specify "model attributes" do expect(foo).to be_valid expect(foo).to respond_to(:color) expect(foo).to respond_to(:height) expect(foo).to respond_to(:some_other_attribute) expect(foo).to respond_to(:you_get_the_idea) end # ... end 

My opinion is that the foo link directly to expect(foo).to respond_to(:color) is the same “duplication” as the indirect use of subject with it , so I’m not too phased about this, and I’m warming like expect specifications are usually read. But ultimately, I think it comes down to being a matter of preferred writing style.