Ever fix a bug you swear you’ve already fixed? Or seen something that was fixed in production 6 months ago and yet here comes another bug report that shows this same issue has somehow resurrected itself and escaped back into the wild?
Could it be you’ve got a lack of unit testing in your pipeline? Did you write a unit test for this the first time you fixed the issue? (Hint: probably not) Large projects add layers of complexity that sometimes make it difficult to understand various dependencies in your code. Nobody likes playing a game of bug-hunt that quickly turns into whack-a-mole. For every bug you fix another one pops up. Unless you’ve got unit tests giving you code coverage for your bug fixes, you could very well end up introducing the same unintended behaviors again and again in your product.
I hear how teams are never given time to write unit tests (as if this should be treated as a separate task), or they’re not sure where to begin, or that the code base is too large, or that the task of writing unit tests to get meaningful code coverage would take too much time.
Could it be that never having the time to write a unit test is because you never make the time to write them? Or you’re too busy fire-fighting in production (because of a lack of unit tests) that you don’t feel you can make the time? It’s like that old quip, “I don’t have time to take a time-management course.”
It’s a vicious cycle that’s difficult to get out of and it takes some discipline to break free. So, what’s the answer?
Start with your next bug report.
Build in the time to write unit tests as part of your estimate for fixing the bug. One lesson I’ve learned from watching classic horror movies is don’t assume the bad guy will stay down unless you make sure they stay down. So, don’t be the hero who quashed the most bugs in the quickest amount of time; Be the one that makes sure these bugs never come back.
Before you dive into fixing the bug, take the time to write a unit test that will duplicate the behavior you are trying to eradicate. This does a couple of things for you right off the bat.
- One, you have to do the research anyway to make sure you understand how to reproduce the bug and verify the fix so you might as well have it scripted out.
- Two, you now have a set of unit tests that you can use to test the code as you refactor and engage in future bug hunts to ensure your code will still work as intended and that you’ve got a real fix.
- Three, now that you have a set of unit tests in place, future developers who come through the pipeline and update or refactor your code are happy to see they have unit tests as well to ensure they don’t add any breaking code to the product.
The next time you are asked for an estimate, make sure you add time to write unit tests. No need to explain your estimation or ask for permission to include these unit tests. If you wait to do the right thing, you will be waiting forever.
If you think you’re actually saving time by not writing these unit tests, the next time you are fire-fighting due to a bug in production, here’s some metrics you can look at to determine how efficient you are by not writing unit tests:
- How long did it take to diagnose and repair the issue in production?
- Was there any lost revenue due to this bug?
- Did the product or company lose reputation because of this issue?
- How many extra hours are you spending playing catch up for all the other items you’ve already committed to for your current sprint because you had to spend additional time firefighting?
Now compare that to the time it would have taken you to just write the unit tests the first time you fixed the bug. It’s a powerful comparison. So powerful that one could even make a case to make it a team policy that every bug fix should be accompanied by its own set of unit tests before being resolved.
In the end, not writing unit tests for your bug fixes is a “short-cut” your team can’t afford to take.