Unit Test Gluttony
One could argue that gluttony is nothing more than a specific case of greed, right? I think that makes sense, and it would make for a shorter blog post. But since I didn’t come up with this list…gluttony it is.
A unit test displays gluttony when it eats too much…of your time, that is. It does this by requiring a very complicated setup in order to run. OK, I know. That was something of a stretch. But bear with me because it’s not without merits. (I wouldn’t put it in the post if it wasn’t.)
A test that requires a complex, time-consuming, error-prone setup is a big red flag because it’s very likely that it also commits many or most of the other sins. If the test is too complex and requires a dedicated setup, it’s probably slow to run (sloth), complex to the point of snobbery (pride), and it wouldn’t surprise me if it has lots of assertions. Such a test is almost crossing the line into integration tests territory (it’s envious of them), so you might as well move it there already! Integration tests are good and desirable things, but they’re different things.
Unit Test Wrath
When does a test exhibit wrath? When it induces anger into the hearts of developers by failing randomly. A good unit test is deterministic. If it’s passing, then it must continue to pass if the code is unchanged. If it’s failing, then it shouldn’t miraculously become green if no one altered the code.
Tests that fail randomly undermine the team’s confidence in the test suite. If slothful tests make developers run them less frequently, then randomly-failing, anger-inducing tests make them stop bothering for good.
Tests that fail randomly probably exhibit the sin of envy. By depending on external realities such as the system clock of the OS culture, they show they’re envious of integration tests.
Wanna Go to Software Heaven? Make Your Tests Virtuous
Since this post is a list of “do nots,” you just have to do the opposite of each item to achieve good unit tests. Write tests that don’t pride themselves in their fanciness but, on the contrary, are easy to read and understand.
Make your tests small, focused, and satisfied with few assertions that are closely related to the specific behavior they’re testing. Create tests that are fast, don’t require complex setups, don’t fail randomly due to external dependencies, and don’t concern themselves with the implementation details of the SUT.
By employing these tips, you’ll be much closer to the promised land of software quality.
Read the complete series here:
Part 1 The Deadly Sins of Unit Testing
Part 2 About Unit Test Envies and What Classes to Watch out for
