Peace of mind

You got a new task, a new feature to add. It’s an exciting combination of the freshness of the approach and confidence in your ability to execute. With rudimentary planning done, you start the work.

Because it’s a non-trivial piece of code you often check it if it matches your expectations. All the intermediary results are correct. The external API is responding exactly as written in the documentation (a rare occurrence).

You can move fast. If you keep the pace, you may finish before lunch.

Because of the velocity, you don’t want to stop and write tests. It would slow you down. Besides those manual checks only take couple seconds. And they give you a great feeling of progress. Why bother with automation.

You finish the code. Last manual check and you can push it to the repository. You hope teammates will be impressed by your speed.

Done. Time to move to another task.

Couple days (or months) later there’s a need to change your code. Nothing big, just a tweak to the internal algorithm. Shouldn’t take you long.

You eagerly jump back. It looks familiar (as it should given that you wrote most of it). But it takes you a while to orient yourself. In the end, you find the place you need to modify and you do your job.

Ensuring that the change actually works is simple. Two checks for two possible input values and you’re convinced it is what’s needed. Time to wrap up.

But you have a nagging feeling. Maybe you should check other cases, the ones not involved in the change, but which the feature was covering. Just to be sure that the whole thing still works.

You do two more manual checks. You are aware that there’re many more cases, but the thought of doing it manually is too painful. Something may be broken, but you will not know. That uncertainty stays with you.

But there’s a simple solution. You could invest a little bit of time to write automated tests. The exact steps you have been performing manually on the way to initial implementation, just automated.

Yes, it’s hard in the beginning, especially when you don’t have any scaffolding for tests.

Investing in that infrastructure pays off a lot.

The least important benefit is that you can save yourself some time when running manual checks. The computer will do all the required steps faster and with more precision. It’s perfectly suited for the job.

The more important advantage is the peace of mind. Not when you develop something initially. At that stage, you are confident in your code and in the fact that you have covered all the corner cases and possible failure modes.

But software changes and some of those changes will break the assumptions you had when writing the code. Without the test suite, it’s hard to know when those assumptions change.

The equally important benefit of an automated test suite is an ability to refactor the code. And to do it with the courage, With the certainty that the code still works as expected.

Without constant refactoring, the living application will start to rot, will start to acquire warts and smells. Will get harder and harder to change. A good test suite helps with preventing that degradation. It still requires work, but with the test suite that work can be done.

I wrote this mostly to myself to remind me why automated test suite is important and why it’s worth to invest time into building one.