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) }
...
我喜欢这些规范,因为如果我的工厂和/或模型中有某种错误,这些规范可以帮助我快速找出错误.
我已经将expect语法合并到所有其他规范中,我喜欢它如何读取,但是如何在这里使用它？一个选择可能是
expect(@foo).to respond_to(:color)
另一个可能是
expect(it).to respond_to(:color)
前者涉及使用应用语法避免的重复,但后者对我来说看起来很奇怪(这可能只是我).
我意识到这个问题更多的是风格,而不是功能*,但是我们的Ruby开发人员都认真对待风格,我想坚持标准的做法,并且具有可读性,惯用的代码.任何帮助是赞赏.谢谢.
更新：我的建议选项都没有实际工作,顺便说一句.他们都抛出未定义的方法’expect’错误.现在我真的很困惑！
考虑到这个错误,我意识到这是因为上面的规范在一行内.那么混淆就是如何用预期的语法写一个单行的块？鉴于此次更新,这个问题非常关于功能,我很高兴听到他人的想法.
4/2015更新
rspec> 3.0已经添加了另一种处理方式,这听起来像是rspec〜> 4.0将会消除应用语法.每个Myron大师：
Some users have expressed confusion about how this should relates to the expect Syntax and if you can continue using it. It will continue to be available in RSpec 3 (again,regardless of your Syntax configuration),but we’ve also added an alternate API that is a bit more consistent with the expect Syntax:
describe Post do
it { is_expected.to allow_mass_assignment_of(:title) }
end
is_expected is defined very simply as expect(subject) and also supports negative expectations via is_expected.not_to matcher.
[…]
In RSpec 3,we’ve kept the should 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 it being disabled by default (or potentially extracted into a seperate gem) in RSpec 4,while minimizing confusion for newcomers coming to RSpec via an old tutorial.
