Why unit tests coverage should be 100%

Writing unit tests is a commitment that a lot of companies and programmers do not make. This is a mistake. Writing unit tests, as well as all automated tests, is an important part of anyone’s software development job.

I have been maintaining a 100% code coverage on all work I do for over 2 years now and I can not go back to anything less. It is ingrained in my own software development methodology. How and why did I start to do this?

I must admit it was partly because of my competitive nature. At the time we were sitting at around 60% code coverage on a few particular files and maybe 70% overall for the project and a work colleague told me that the rest was “not testable”. I took that as a challenge. It was a fun challenge to do something that I was not sure I could do. Most of the hard to test areas were anonymous functions. The files that were not being covered had quite a few of them. I managed to solve it and got those files to 100% coverage. It was a great sense of accomplishment. After that I decided, why not get it all to 100%? So that is what I worked on during every story. Add a little more here and there or sometimes large percentages.

All this became a game to me. How much could I increase the percent this time? Can I even test this? It became… fun.

I did get the codebase to 100%. It is staying that way. In fact, if it is not 100%, we have a linting rule (it is a Javascript project by the way) that will fail the Jenkins build if that percentage is not met so now my colleagues get to enjoy the fun as well (I say with an evil grin).

So was it worth it? I would say yes. Not only is it a great learning experience for all, because you are forced to write tests that you thought were not possible or are too lazy to write. Additionally, we have also not had any major incidents.

I also recommend adding the desired coverage as a requirement to your build as a rule. There have been a couple of times where I have thought I covered everything but I didn’t and the pull request build failed it.

Do note that I do not advocate just writing tests for coverage. Think about scenarios and write them based on function input or use cases. In other words, you may be at 100% coverage, but you still may be missing tests because valid use cases are missing.

Happy test writing.

Get better NOW at unit tests with React Testing Library

ByLuke October 5, 2021November 6, 2023

There are a lot of examples out there for writing tests with react testing library that I wish did not exist because they meant spending years with ineffective tests. Not considering how you write your tests can lead to flaky tests, hard-to-maintain tests, and tests that don’t do anything or what you think they are…

Clean Code

Become a clean coder – use storytelling

ByLuke September 27, 2021April 25, 2023

Writing clean and easy to read code is the benchmark for a good developer. A lot of developers have the mentality to write working code first, then focus on code that looks good. I challenge that mentality because code defects are almost certain to happen, at the very least it is most likely that someone…

Clean Code

Create better code – avoid using variables unless necessary

ByLuke September 29, 2021September 30, 2021

One of the most frustrating things a developer can deal with is hard-to-find bugs. Creating variables is one of those things that are best to avoid where possible. It is an approach to improve software quality by reducing the number of possible bugs and improving readability. In JavaScript, use const instead of let. In Java,…

Clean Code

When is code duplication better than reusable

ByLuke December 10, 2021

When writing code you should be thinking about making your code reusable. It is part of every good programmer’s toolbox. After all, it can save a ton of time on maintenance. But it does come at a cost. There are times where you should strive for making your code as reusable and generic as possible….

Similar Posts