Background

Recently, I came across a job posting where it had this line in the requirements section: Should be able to explain the reasons for writing test code from personal experience. Immediately after reading it, I thought it would be a good topic for the next article. Because I like to organize my thoughts and experiences in writing. Additionally, I have been writing tests religiously for the past year. Thus, it seems to be a good time to organize my findings and insights gathered over the past year of testing. This article will not be about how to write test code or best practices but about the reasons behind my dedication to this practice. Who knows, it may serve as a helpful documentation resource that can guide me in future endeavors, such as introducing a testing culture to a development team.

TL;DR

For a concise summary of this article, here's a tl;dr version: I write test code because they ask about it in job interviews. Yes, you read it right, it's that simple. Come on, there is no bad in it. I need to get a job and pay the bills, put the food on the table.

Just kidding! There is no tl;dr, you have to read along 😀.

I have no time

Yes, you read it right, I write test code because I have no time. It may sound counterintuitive because writing tests takes extra time. Writing test code, building, and verifying all take extra time than just implementing a feature and shipping. However, that holds true until you go into production. Picture this scenario: you've successfully shipped a newly implemented feature into production, only to encounter an unexpected error. Then you start checking logs, reproducing the issue, debugging, checking the side effects and so on. After fixing the bug, you build the code and deploy it one more time praying that this time nothing crashes. If everything goes well, fine, but what happens when there is another error that you didn't expect? You repeat the previous steps. Now imagine you had thorough and appropriate tests in place when you were implementing that new feature. All this extra work could have been avoided in your local development environment even before you push the code to the repository. Therefore, testing ultimately saves time in the long run when it comes to production.

I work in a startup

You may find it another counterintuitive statement since in startups you have to deliver as fast as possible. But let me explain the reasoning behind it. The startups usually don't have a specific or fixed set of requirements. As a result, you have to be prepared for any unexpected shifts. This constant adaptation and integration of changes don't come easy when you need to maintain the stability of the codebase without breaking. Here, extensive coding efforts are to rescue. Otherwise, you find yourself in recurring issues similar to those discussed in the previous section.

Documenting business logic

Tests are a great way to document business logic. They act as living documentation, describing how the code should behave. By writing tests, developers can clearly explain and demonstrate how different parts of the software should work. Tests serve as a reliable reference, making it easier for others to understand and maintain the code. Tests also play a significant role in facilitating smooth onboarding. When a new member joins the team or a project, having well-written test help them quickly grasp the intended behavior of the codebase.

Detecting design issues earlier

Another aspect of testing that I love is its ability to uncover architectural or design issues. Poorly designed code is always difficult to test. As an example, let's say you want to test a unit or one method of the class. However, just to be able to test a small unit of the code you may find yourself injecting unrelated dependencies(even if they are just mocked) into the class under the test. This may be a good signal for you to detect that the S principle of SOLID was violated when designing this class.

The joy of refactoring

I can't be the only one among developers who looks at the code they wrote two months ago and says, "Who on earth wrote this code?" and replies "Oh, it's me." I, as a developer (a special kind of human being), can't write perfect code from the beginning. Wait there is no perfect code but only a good enough one. So I start with imperfect code and continuously refactor until it makes me feel "Now it's good enough". Having tests in place gives you the confidence to make changes to the codebase without worrying about breaking.

Conclusion

I've introduced to you some of the reasons why I am passionate about writing test code. In my upcoming articles, I may write about my testing practices and share insights on "How Do I Write Test Code?". But for now, that concludes our discussion.

Happy coding!