The Unit Testing Quandary
I’ve worked on a handful of projects in my still fledgling career, and I’ve seen several takes on unit testing in each of those projects. Here are a few things I’ve heard people say about unit testing, that I don’t agree with at all.
I write perfect code, so it does not need tests.
Besides the fact that it sounds very conceited, it’s also a very ego-centric way of thinking. Calling your own code perfect is debatable, which is why we have a peer review process before code is checked-in.
Writing tests pushes out feature delivery timelines.
This usually tends to be the way a product manager thinks, and it is absolutely true. When we’re building out an MVP that is going to be thrown away, it makes sense to overlook unit tests. But that way of thinking needs to change when we’re building out a complicated product, because unit tests ensure long-term maintainability of a feature.
Unit tests are another thing that needs maintenance in a codebase.
I’ve heard a few people argue that unit tests are expensive to maintain in a codebase. Tests are code too and they do need to be maintained, but unit tests are actually quite easy to write once you get the hang of it.
I have to modify tests every time I make changes to a feature.
That is the whole point of writing tests! When you see broken tests, you know something has changed. Sometimes those changes may have been unintentional or many have unforeseen side-effects.
We need 100% code coverage.
Having 100% code coverage is a great target to have. Sometimes it’s easy to get really close. It’s always the last 5% that kills you. The cost of getting the last 5% of code coverage may outweigh the benefits by a mile. That’s when we can replace that unit test with a scenario test.
Most of the negativity around writing unit tests stems from a lack of experience writing tests, strict deadlines or just a disregard for other programmers on your team. It’s hard to have arguments with people when you know that their points of view are baseless. Nevertheless, I think unit tests are an absolute necessity for any project of reasonable complexity. Unit tests are quick and easy to write when you’re in the groove and they are an insurance policy that protects you from an unforeseen catastrophe that awaits the project. I’m going to list a few, not so apparent, advantages of having tests from my experience.
1. Bug-free code with TDD
Test driven development is a very idealistic way of thinking for a software developer. If it is indeed followed, then your code is going to be almost bug-free. You tend to think through and cover each and every edge case in your implementation of that feature. Even otherwise, I’ve found that I realize that my code does not work the way it’s intended to while writing tests for it. This definitely saves us time as a team. Less bugs means that QA has one less bug to file, that has to be prioritized, assigned and then worked on. It may seem trivial, but these tiny bugs definitely add up.
2. Forgetting features
As a developer, I definitely tend to forget some finer details about how a feature is supposed to work. Those finer details are sometimes not very obvious from just looking at the code. When you come back to a chunk of code you wrote a year ago, the unit tests are a handy tool to help understand what it is doing exactly.
3. Protection against staff churn
In a large project that is moving really fast, with continual staff churn, the only way to ensure productivity and knowledge transfer of features is unit tests. A new developer understands a feature better when there are unit tests to look at. I have definitely found myself in the situation where I’m looking at spaghetti code and wishing it had unit tests that would prevent me from completely unravelling a feature.
Summary
Unit testing is awesome and we have to be more accepting of it. In a long term project, especially in a javascript(thanks to its quirks) codebase, tests are important. It’s also a useful skill set to have and it definitely looks great on your resume if you are adept at it.
