When it comes to unit testing most people fall into one of two categories. Unit testing advocates and unit testing sceptics. The reasons there are unit testing sceptics can often be from bad test implementations. Created by unit testing pitfalls.
Unit Testing pitfall 1: Not knowing the why
When we test it’s important to keep the goal in mind. People cite many reasons for applying unit-testing, such as:
-
Tested code is better code.
-
Tested code has documentation.
-
Tested code is easier to read.
-
Tested code is easier to update.
-
Tested code is more stable.
-
Tested code is easier to refactor.
-
Tested code is better for on-boarding.
-
Tested code extends the product lifecycle.
-
etc.
Yet, none of these factors matter. Building software is about delivering things of use. From testing there’s only one thing that really matters…
Unit Testing pitfall 2: Focusing on coverage
When it comes to unit testing. One of the first things we often want to understand is coverage. Metrics themselves can be dangerous. And sometimes when we try to generate a metric, such as coverage we get an unintended side-effect. By focusing on the wrong thing. Economists call this the Cobra effect.
A great story that shows this problem comes from Hanoi in Vietnam. Vietnam was suffering a rat problem at the time. So the french colonial regime created a bounty program to pay a reward for captured rats tails. But what happened is that they returned the tails but free’d the rats! Creating more revenue for the bounty hunters.
As the story shows when we focus on a metric we often cause an undesired side-effect. This is often the case with code coverage. The concern turns to how to reach 100% as opposed to making the tests useful. 100% coverage with bad tests equates to thousands or millions of lines of technical debt.
Unit Testing Pitfall 3: Tests that don’t tell you anything
When you’re certain you did something right, the test should be there to tell you when you’re wrong. If the tests only tell you things you already knew, they’re standing in your way. Instead we should focus on how we can check for ways that the code might behave in manners that we wouldn’t expect.
An anti-pattern of test coverage is unit testing things like variable assignment. In assignment there is one input and one output. There is 0 complexity and this is a fruitless test. Instead of telling us something new, this casts our code into stone. Now if you want to rename the variable you have a bunch of failing tests which tell you nothing new.
Key Points
If you’re not sold on unit testing. Try focusing on the reason for unit testing as sustainable delivery. Don’t focus too much on coverage, instead focus on quality. Try to write tests that tell the future programmer something they didn’t know about the code.
What types of unit testing anti-patterns have you seen?
Hey I'm Lou! I'm a Cloud Software Engineer From London. I created Open Up The Cloud to help people get their start and grow their careers in cloud. I edit the monthly Open Up The Cloud Newsletter which I think you'd really like. You can find me on Twitter or LinkedIn , I'm always happy to chat. When I'm not writing you can usually find me picking up heavy things and putting them down, or riding two wheels (sometimes with an engine, sometimes not).
Latest posts by Lou Bichard (see all)
- 2023 Summary: Data Driven Stories About The Cloud - December 31, 2023
- 2022 Summary: The Open Up The Cloud System - January 1, 2023
- Open Up The Cloud Newsletter #30 (January Recap 2022) - March 1, 2022
