Question

Betterspecs建议使用以下内容：

subject { assigns('message') }
it { should match /it was born in Billville/ }

作为良好做法。但是如果我想以doc格式（rspec -f doc）运行rspec，我收到了：

When you call a matcher in an example without a String, like this:    
  specify { object.should matcher }    
or this:    
  it { should matcher }    
RSpec expects the matcher to have a #description method. You should either
add a String to the example this matcher is being used in, or give it a
description method. Then you won't have to suffer this lengthy warning again.

所以这个

it "some desc" do 
  should match /it was born in Billville/ 
end

不会引起那令人讨厌的消息，但看起来很难看。

关于如何保持rspec约定和代码干净的任何想法，并且仍然有一些漂亮的输出（比如-f doc）？

rspec v.2.13.0

Answer 1

作为RSpec维护者，betterspecs.org上列出了许多我不同意的东西。几个月前我就该项目的github问题对此进行过评论，但遗憾的是，我认为我的任何问题都没有得到解决：（。

无论如何，我认为当doc输出与你想要的匹配时，单行语法可以使用，但通常不会。通常，单行语法的doc输出过于具体，例如它返回文档字符串，如should eq "dfgh"，即使这不是一般的真实行为 - 像returns a string without vowels removed这样的行为更好，更一般地说是真实的。

所以我的建议是不使用单行语法，除非它产生你想要的输出。不要因为betterspecs.org推荐它而使用它。在我看来，它的许多建议都是不好的建议。

Answer 2

就个人而言，我同意BetterSpecs的观点。关于以下内容有什么难以理解的？

subject { assigns('message') }
it { should match /it was born in Billville/ }

如果像@Myron Marston所说，它没有产生足够好的输出，那么我建议（我总是这样做）使用上下文，例如。

context "When given a message" do
  subject { my_func arg }
  context "With vowels" do
    let(:arg) { "dafegih" }
    let(:expected){ "dfgh" }
    it { should == expected }
  end
  context "Without vowels" do #…

你会得到可爱的输出，它也可以很好地读取代码，简洁，并鼓励你思考不同的输入，并通过共享的例子和上下文重用，然后鼓励在更广泛的输入上进行测试。使用基于字符串+块的编写规范的方式鼓励将几个规范塞入一个测试中，例如。

it "some desc" do
  should_not be_nil
  should match /it was born in Billville/
end

如果失败是因为它是零，或者因为它不匹配？这会鼓励重用吗？这要好得多，IMO：

subject { assigns('message') }
it{ should_not be_nil }
it { should match /it was born in Billville/ }

很高兴图书馆的作家和维护者打算让我们很好地使用图书馆，但我有点厌倦他们认为他们可以唠叨我们或强迫我们做这些事情。 RSpec已将自己添加到列表中，其中包括Bundler和Rails，其中包含“非常有用的项目，我真的非常感激，但应该从我的业务中解脱出来”。

使用--format doc保持rspec约定

2 个答案: