3 ms·

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 h

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.

erikpukinskis 16y ago
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.