1

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 约定和代码干净的任何想法，并且仍然有一些漂亮的输出（比如 with -f doc）？

rspec v.2.13.0

4

2 回答 2

5

作为 RSpec 维护者，betterspecs.org 上列出了很多我不同意的东西。几个月前，我就该项目的 github 问题发表了这样的评论，但遗憾的是，我认为我的任何担忧都没有得到解决:(。

无论如何，我认为当 doc 输出与您想要的匹配时，可以使用单行语法，但通常情况并非如此。通常，单行语法的文档输出过于具体，例如，它以文档字符串的形式返回，should eq "dfgh"即使这不是一般真实的行为——类似的东西returns a string without vowels removed是对行为的更好、更普遍真实的描述。

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

于 2013-03-01T20:11:29.390 回答
1

就个人而言，我同意 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 的列表中，标题为“非常有用的项目，我真的很感激，但应该退出我的业务”。

于 2013-10-04T02:16:47.757 回答