Why should you care about unit tests?

A good question with a long incoming answer. In short because it helps you with the product development lifecycle. In long? Well, that is going to follow.

Unit testing is a practice that is quite known and established in the development industry by now so for this reason we won’t go into explaining what unit testing is, as there are a lot of great resources already available.

When a product is developed from scratch, in agile methodologies there is a fast iterative process of development, testing and acceptance, getting feedback and iterating upon that feedback. Usually a software product lifecycle goes through multiple phases from “building fast and breaking things” to “slow and steady”.

Unit testing as a practice is sometimes overlooked as the benefits in the first phase of “building fast and breaking things” are not quite seen or the practice is not seen as a need in order to build and deliver a “good” product from the technical standpoint.

There are some reasons for not doing or not being able to do unit testing and those range from the already known “lack of time” to “we have developed our products without unit tests and they are fine” and many other reasons.

True, not everything is perfect and there is no magic solution in software development. Like everything else, unit testing comes with a cost and that cost is the time that developers must invest in order to develop and maintain those unit tests.

What I want to tell you is that the benefits outweigh the costs and here is why:

I. You WILL find bugs while developing tests and increasing code coverage

This is something that I was quite surprised when I started developing and making sure unit tests are part of the development process. Most of the time when a developer finishes developing a feature, it tests by itself to make sure it’s working. While this is okay, of course it’s not perfect. When I started to add unit tests and make sure I covered everything that needed to be covered, there were more than a few cases where I found some bugs in the code and fixed them before going to QA/release!

Of course this gave a confidence boost that what was developed is more stable and reliable.

II. Adding new functionalities to already complex ones will become easier

You’ve probably met until now a product that is mostly okay regarding complexity, but there are some parts of it that you would not want to touch even with a 10 feet pole. Most of the time, those parts are hard to understand as they have a lot of business cases that must work even after you’ve added or modified a functionality in that feature.

It could be the case that you don’t even know what are all those business cases that it must fulfill, so testing manually and making sure you haven’t broken anything is close to impossible.

Unit testing to the rescue! If all of those cases are already covered by unit tests, then instead of wasting time manually and making sure nothing is broken, the tests can be run and most of the time in a few minutes you can see if something is broken. Of course, don’t forget to add tests to the newly created cases!

III. It reduce development time in the long run

This is something that developers might not be that interested in, but a lot of parts of the company that depend upon the output of the development teams would love to hear.

Though, usually this is seen in later stages of the development lifecycle and it’s closely correlated with the previous point. After most of the features have been built, of course there will come change requests/adding new functionalities to existing features.

And that is good! It means the product is gaining traction internally or externally. Though, when a product matures, it gets harder and harder to add features to it and developers must struggle with the existing code complexity, properly manage it and ensure nothing is broken at the end.

Without an automated process that can tell in a few minutes at most if something is broken, it’s like shooting in the dark and hoping you only hit what you wanted.

With good code coverage the iterative development process becomes faster and more reliable. When they finish, developers are relaxed that nothing is broken and the business departments are happy “it didn’t take that long”!