CODEWITHSUNDEEP
ruby-on-railsrubyrspec
ted
ted

Reputation: 5329

Keeping rspec convention with --format doc

Betterspecs suggests using something like:

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

as good practice. But in case i want to run rspec in doc format (rspec -f doc) i'm receiving:

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.

So this

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

won't raise that annoying message but seems ugly.

Any ideas on how to keep rspec conventions and code clean, and still have some pretty output(like with -f doc)?

rspec v.2.13.0

Upvotes: 1

Views: 576

Answers (2)

ian
ian

Reputation: 12251

Personally, I agree with BetterSpecs on this. What is so difficult to understand about the following?

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

If, as @Myron Marston opines, that it doesn't produce good enough output, then I'd suggest (and I always do) using contexts, e.g.

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 #…

You'll get lovely output, and it also reads well as code, is terse, and encourages you to think about the different inputs, and reuse via shared examples and contexts that then encourages a test across a wider range of inputs. Using the string + block based way of writing specs encourages several specs to be crammed into one test, e.g.

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

If that fails was it because it was nil, or because it didn't match? Will that encourage reuse? This is far better, IMO:

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

It's nice that the writers and maintainers of libraries intend for us to use libraries well, but I'm getting a bit tired of them thinking they can nag us or force us to do these things. RSpec has added itself to the list that includes Bundler and Rails headed "Projects that are really useful and I'm really grateful for, but should butt out of my business".

Upvotes: 1

Myron Marston
Myron Marston

Reputation: 21820

As RSpec maintainer, there are many things listed on betterspecs.org with which I disagree. I've commented as such on the github issues for the project many months ago, but sadly, I don't think any of my concerns have been addressed :(.

Anyhow, I think the one-liner syntax is fine to use when the doc output matches what you want, but often it does not. Usually, the doc output of the one-liner syntax is overly specific, e.g. it returns in doc strings like should eq "dfgh" even though that is not a generally true behavior -- something like returns a string without vowels removed is a better, more generally true description of the behavior.

So my suggestion is to not use the one-liner syntax unless it produces the output you want. Don't use it just because betterspecs.org recommends it. Many of its recommendations are bad recommendations, in my opinion.

Upvotes: 5

Related Questions