Why I don't miss Minitest
I've just got back from BrightonRuby, which was excellent. Lots of great talks, meeting up with old friends and making some new ones. A big thank you to Andy Croll and his team for a great event.
One of the lightning talks was titled "Why I don't miss RSpec" by Murad Iusufov, who works for one of the conference sponsors, Cleo. At Cleo they use Minitest, not RSpec, and Murad's talk was about how he found switching a breath of fresh air.
To paraphrase his reasons, RSpec is a big and complicated DSL that takes time to learn. The specs that it produces are often hard to follow - excessive nesting and sprinkling subject
and lets
all over the place mean fundamental setup happens far away from the stuff that matters.
Whereas, Murad says, with Minitest you create a class and write methods. When he's writing tests, he's just writing code.
And this is where I disagree, as we're about to find out.
To be fair, some of the criticisms are valid.
RSpec has a lot to it and takes a bit of time to learn. And you can end up writing incredibly hard to follow specs. But, more importantly, RSpec is hard for non-native English speakers.
This final problem is one I sympathise with because it's very hard for RSpec to fix this. RSpec is deliberately designed that way. And it's designed that way because when I'm writing RSpec, I'm not writing code[1].
When I'm writing RSpec I'm writing executable documentation[2].
When I'm writing RSpec I'm writing a plan for my next bit of work.
When I'm writing RSpec I'm writing a description of how I expect it to behave.
When I'm writing RSpec, I am writing a specification[3].
When I did use Minitest for a couple of years, I wrote awful code. The tests proved that it all worked but the code was muddy and unclear. This is not a coincidence. My thinking was also muddy and unclear ↩︎
Executable documentation - isn't that amazing? ↩︎
So if you do have a crappy hard to follow spec, you've actually written a shitty hard to read bit of documentation. Please go back and rewrite it. ↩︎