André Carlucci

Skeptic .net development

10 Reasons why you should start writing unit tests right now

Writing unit tests requires a lot more coding than simply implementing the desired functionality. So, is it worth it?

It’s 2021 but I still get this question all the time. Hence, I decided to select 10 reasons why I think you definitely should.

Reason 1: It’s safer to change code covered by Unit Tests

Your project will grow and it will become increasingly difficult for a single person to know and understand all its lines of code. At the same time, the risk of changing one part of the system and causing unexpected behavior in another also grows, aka bug. Not to mention when you just started as a new team member and have to write a new feature. How do you know that your changes won’t break anything?

Unit tests are your safety net in these scenarios. You can make your changes, run the tests, and have the peace of mind that everything still works as it should. This is as useful for an unknown territory as for when you are writing a complex algorithm and need to make sure that every small step is going forward without leaving anything behind.

Reason 2: Unit Tests are a great form of documentation

When you start working on a new project, one of the best ways to understand all business rules is by reading the unit tests. For example, take the following tests:

They tell you right away what they are testing, and therefore, how the system works. Of course, this only works if you name your unit tests properly, which is absolutely important to do from the beginning.

Reason 3: Unit Tests are the best way to learn how to use a new library

Extending the concept of Unit Tests as a good form of documentation, they are even better when you are learning a new library. This happens because usually, library authors write the tests from the perspective of the user. Therefore, you will find all the use-cases of the library, including the edge ones, in the test suit. Every time you decide to use a new library, all you have to do is to head up to Github and read the unit tests. You will learn how to use it in a much faster way.

Reason 4: Get back to work faster every morning

One thing I like to do after a day of programming is to, after my last commit and push, write the next unit test with an implementation that makes it fail. The next day when I start, I simply run all the tests and I know right away what the next step is. Easy!

Reason 5: Writing the tests before the code leads to better code quality

This is exactly what Test Driven Development is all about. You first write a failing test. Then, write only the code necessary to make it pass. Once your test is passing, you are free to refactor your method as much as you want and your test will guarantee that everything stills works. That way, we are sure that all our code is tested.

Reason 6: Unit Tests are automated tests that can be run in a CI server

“It works on my machine” is not a valid excuse for a bug in production. Every time code is sent to the version control a pipeline should build the code and run all the tests to make sure that everything is running fine not only locally, but also in an independent machine. That way we protect the system from ambient problems before it’s too late. Never forget that your laptop has dozens of tools and frameworks that probably a production server doesn’t have.

Reason 7: Unit Tests facilitate teamwork

As developers, we seldomly work alone. Your teammate will change code in the same project as you and often even in the same file. If everybody writes tests, as this code is merged together, they will guarantee that what you have changed didn’t break your teammate’s code and vice-versa.

Reason 8: Refactorings are easier with Unit Tests

A well-covered code is much easier to refactor than a non-covered one. If you change non-covered code, how can you make sure that it still works the same way without long sessions of debugging and manual testing? On the other hand, with a good test suite, you can easily change large sections of code and just run all the tests on each step to be certain you didn’t break anything. It’s safe to say that unit tests make us more confident.

Reason 9: Fast feedback

Without tests, you have to use your debugger all the time. The only way to know if something works is to debug the application and go step by step to check the results. When writing unit tests, you get instant feedback any time you want and some IDEs will even run all of them constantly in the background. A fast feedback cycle helps us to keep a higher focus and to be more productive.

Reason 10: The same bug won’t ever come back again

Every time you find a bug in your application, before writing any code to solve the problem, create a test that fails because of the bug. After that, write the code to fix the problem and make sure your test passes. With this test in place, the bug will never come back.

When would you not use unit testing?

Like any practice, you should only use it when its benefits outweigh its costs. We have seen 10 good reasons to write unit tests above but, of course, there are situations where they are simply not worth it. This will clearly vary from person to person and context to context but a good example would be when you are trying out a new framework or library for the first time and you don’t know exactly how to use it or all its features.

The freedom to write code without thinking of consequences will bring speed and creativity. After that stage, there comes the time to organize your project, start again and add your precious tests to it. Your future you will definitely be grateful down the road for it.