与--format DOC

Question

Betterspecs饲养rspec的约定，建议使用类似：

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问题上评论过，但不幸的是，我不认为我的任何担心都已经解决:(无论如何，我认为单线程语法没问题在文档输出与你想要的相匹配时使用，但通常情况下不会，通常，单行语法的文档输出过于具体，例如它会以文档字符串的形式返回，如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马斯顿冠瘿，它不会产生足够好的输出，那么我会使用上下文提示（我总是这样），例如

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领导的“项目，这些项目非常有用，我非常感谢，但应该从我的业务中剔除”。