I was thinking: Why not post about test anti-patterns? Then, after I got this cool title, I knew I couldn’t pass this up.
Tests, like everything in life, have both patterns and anti-patterns. Anti-patterns are patterns which end up badly. Much like in Pet Sematary, you may feel you’re doing something good, only it comes back to haunt you.
So here’s one that is a popular with the noobs. Meaning, if you’re starting out in unit testing, there’s a good chance you’ve done this. If you did, once you’re done reading this, go back and fix this.
On to the first anti-pattern. We all know that AAA stands for Arrange-Act-Assert. Sometimes, as we write tests, we forget the final A. Hence the AA (It is not necessarily alcohol related. But could be).
Why do we need an Assert anyway?
A computer may have good intentions, but it is not a mind-reader. Without a specific pass/fail criteria it won’t know if the test needs to pass or fail. And given our regular toolset, is bound to give us a bad answer some of the time. That’s a problem.
You see, when we see a green result, it means the test passes, and therefore does not require more handling. When it’s red, it requires investigation. If we can’t rely on the test to report a failure ONLY when there is really one, we’ll lose confidence in our tests. We will not trust them. Our relationship with tests boils down to trust. If we don’t have it, why bother?
Our tests need to fail when the specified Assert fails. Only then. And when the test fails, we’ll know how to fix it, because we know what to expect – based on the Assert, of course.
So how does this pattern appear?
The anti-pattern is seen more with people who are just starting to write tests. The blame is really with our tool set: Write an empty test, run it, and what do you have? Green success!
What beginners do, is write a bunch of operations. The test passes (only because it doesn’t throw an exception). Now we have a deceiving test. It doesn’t check a result, but only that operations are performed in sequence, and doesn’t throw an exception on the way. It may return different results in different run, but since we’re not asserting on the results, we’ll never know.
What’s the good news?
In order to remedy the situation is (drum roll)… write an Assert. Sure, that means you’ve put some thinking into your test, but I can ask for this much, right?
How do I identify the situation?
Remember the law of the nearest ear? Grab a teammate by the ear, and make her review your tests. Between the both of you, I’m sure you’ll see if there’s a problem. And, if you’re using Isolator, it has a cool test review feature. It looks for this issue, as well as others, and will let you know if you’ve made the AA mistake.
More to come. In the meantime, what’s your favorite test anti-pattern?
