Introduction
Often, especially in the early stages of projects, I kept hearing from software developers that unit tests are a burden and not needed. Here is a list of common excuses:
- our software is not mature enough to cover it with unit tests
- we don’t have enough time for that
- anyway, our solution is temporary
- our developers are senior and write bugs free code
- you spend more time updating the tests than writing the code." and that is considered unproductive
- it doesn’t improve code quality
- it leads to unit test-oriented design 🤦♂️
From my perspective, all this reasoning against unit tests does not beat the benefits they bring in. In this article, I try to list the reasons to write unit tests. Feel free to use these arguments to convince your colleagues or managers.
Better API design
You get better API design when you think from a consumer perspective. And it’s rather hard to look at interfaces from a client/caller perspective if you are only implementing them. Let unit tests help you. Allow them to be your first clients. Using your code before finishing implementation helps to make a better and more thought-out design. With unit tests in place, you will never design APIs hard to call and use. For example, you won’t create a method that accepts 7-10 boolean params. It is a nightmare to use such methods, and you will avoid it at all costs.
Verify your code right in IDE
It is necessary to verify your software periodically writing coding. Usually, verification requires one or multiple of the following actions:
- launch your app
- go to a terminal window to see the output
- open a browser and perform interactions and visual confirmation
- call some REST/gRPC calls and verify response/app state
All these actions are disturbing and force you to leave your IDE. This change causes your brain to switch context and distract from coding mode. But tests come to the rescue once again. Today most IDEs capable of running tests with a single hotkey press. This feature allows you to stay focused on your tasks undisturbed. All you need to do is to run tests periodically and let them verify your solution.
Independent development of components
This argument derives from point #1(Better API design). Unit tests act as a bridge for back-end/front-end development, multiple services developments, or multiple teams working on a complex system. All you need to do is to agree on a communication contract. Then you can do independent development and testing of separate services by just writing contract tests or mocking contracts.
Protect code behavior
Unit tests perform as warriors protecting the expected behavior. Anyone changing the existing code and causing the test to fail would think twice before making the change. Moreover, it is always a pleasure to get an immediate response on the code change. 😉
Tests are alive dev docs
This point is somehow related to the previous, but I think it deserves a separate paragraph. We live in the dynamic world of constantly changing requirements. Our tech documentation is not always able to keep up with the implementation. Tickets in the tracking system are not updated to reflect all changes applied to the code. In this case, unit tests might be the only source of truth. The better they are, the easier it is to maintain and enhance such a project. Having tests run as a part of your CI makes sure that your “dev docs” stay up to date.
Summary
This article is not complete and frankly speaking, I don’t think it will be complete ever. I will continue filling it with more reasons to convince you and your colleagues to write unit tests.