I’d like to point out a really nice testing practice that I’ve been loving more and more lately.
Just about every mature testing framework out there supports the concept of custom matchers, which provide us with the ability to define our very own assertions seamlessly into the tests. Even though this ability is quite old, we don’t see it used too often and I think that’s a shame. I’ve seen this practice heavily used in the mind expanding GOOS book and just now am starting to realize its awesomeness.
Creating your own matcher usually means creating a Matcher class that performs the assertions, supplies human readable error messages and a nice constructor.
Here’s an example from the RSpec documentation:
Matchers increase readability and intent
As you should know, one of the most important rules for design is Reveals Intent. Take a quick look here, which way do you think reveals more intent?
Also, which error message do you prefer? “expected false to be true” or something along the lines of “expected comment to be anonymous”?
Matchers create robust tests
The most important advantage of all is how using matchers easily allows you to steer away from fragile tests which are the bane of a lot of testing efforts. The mark of good tests is that a change in your code doesn’t require you to perform changes in multiple tests that don’t really care for the change. Take this code for example:
This might seem like a standard test, but that’s not really the case. A test should assert for a single piece of knowledge, and this test actually checks several. If the purpose of this test is to check the behavior of anonymous comments, why should it change if we no longer allow replies? Or if we no longer require users for posting comments?
The magic of matchers is exactly here. You create a new matcher to check specifically the aspect your test cares about and boom, you’re decoupled!
This simple change makes your tests DRY and cool.