Comment by jameskilton | Hacker News Reader

Comment by jameskilton | Hacker News Reader

Parent Full thread

Frankly, if there's one part of RSpec I wish never existed, it's the 'be_' construction. If tests are supposed to be part of the documentation on how to use the code, then in this case Rspec actually hurts you. I've been converting all my be_ usage (except for be_true, be_false, and be_nil) to the following:

frood.hoopy?.should be_true frood.knows_where_its_towel_is?.should be_false

Now you know exactly how the code works (this is the method name, it returns a boolean), vs:

froot.should be_hoopy

which requires you to be very familiar with Rspec to know that it will magically add the "?" when searching for the method, and the "be_" is extraneous to allow "readability".

Though back to the OP, if you want tests that read like manuals, Rspec is the wrong place to look. Tools exist explicitly for this purpose, namely Cucumber. Code is code, and it's always going to look like code. Any attempts to make it read more like English gets you into the realm of ridiculous verbosity or code explosion as you keep abstracting to give you things that "read good".

which requires you to be very familiar with Rspec

This sort of thing will likely be surprising to someone new to Rspec. However, as a general rule, I don't think it's fair to knock tools because they're a bit tough for new users to understand. Someone new to vim is hopelessly lost and slow at first, but I can fly with it, because I've taken the time to learn it.

Yes, I had to invest some time to learn about Rspec's 'be_' construction; yes, it confused me at first. However, having learned it, I always use it now. I really enjoy the readability of the code that results from it.

As in many things, there is a tradeoff here. It's fair for both of us to argue that we prefer to sacrifice different things.

There's a difference in the error messages each produces if the assertion fails.

    frood.should be_hoopy

will output something like "#<Frood:0xabc> should have been hoopy, but wasn't", which often makes it easy to see at a glance what bug your code change has introduced; whereas

    frood.hoopy?.should be_true

will output "expected false to be true", which is very Zen but not so helpful for debugging.

This. I actually wish the be_ facility worked for methods besides booleans. Like:

    it do
      frood.should be_hoopy_for(apples, oranges)
    end

Which would say "#<Frood> should have been hoopy_for #<Apples>, #<Oranges>". There's real value in giving your test infrastructure more responsibility for actually piecing together the assertions. Not only does it give you better error messages, it lets you avoid having to write so many explanatory labels for all of your assertions.

> Now you know exactly how the code works (this is the method name, it returns a boolean)

No you don't. You know it returns something falsey e.g. nil.

Your right, I had a mind fart when I wrote that. I couldn't come up with the proper term (truthy / falsey) at the time.

Reply on news.ycombinator.com