January 7, 2015

...Learn TDD with Codemanship

Do Matchers Really Make Test Code Easier To Understand?

Just time for a quick Thought For The Day about using matchers in unit test assertions.

Have a look at this simple example:

And now again without matchers, the old-fashioned way:

My first question is this: is the version using matchers easier to read than the traditional version? Really?

My second question is: should unit test assertions ever get complex enough to benefit from matchers? (The old "tests should only have one reason to fail" principle.)

And finally, when test code starts to get "smart", does that perhaps indicate sometimes that we've discovered some useful model code and should refactor to move it to the most appropriate class in our implementation?

In which case, does using matchers help or hinder in that respect? I'm not a big fan of having my implementation depend on Hamcrest libraries, especially if the tests do, too.

If I refactored the traditional version like so:

...then is that more readable than the version using matchers? To my eyes it is. And I tend to find that generally. Not always, but often, I have a harder time wrapping my head around assertions written using matchers than traditional assertions.

When assertions get complicated, I can't help feeling that's my test code trying to tell me something. Matchers make it more difficult for me to respond to those clues.

I'm wondering, even, if maybe I could try pairing test code all the way back to only using a simple Boolean assertion, and letting it all "hang out" to see what logic emerges beyond a simple TRUE or FALSE.

What do you think? Do matchers really make test code more readable? Have we tested that assumption? How would we test that assumption? And what impact do matchers have on the "refactorability" of our test code?

There. I've said it. "Burn the unbeliever!" etc.


So, thoughts are pouring in via the Social Mediums and That Email That They Used To Have. Most defences of matchers centre around the more informative test failure reporting. I can see how that might help, but in practice haven't always found that "more information = better".

@c089 suggested I look at Groovy's Power Assert, which has the purity of simple Boolean assertions with the diagnostic advantages of using matchers. I shall ask Santa for a Java version and a .NET version of this, because it looks jolly useful.

The jury's out on whether assertions using matchers really are easier to read. Not many have defended them on those grounds so far. I would like to put it to the test. (Puts thinking cap on...)

Posted 2 years, 11 months ago on January 7, 2015