Registration for Kuali Days is now open!

100% Code Coverage is the Bare Minimum

July 2, 2019

On my last three production web applications, before I wrote the first line of code, I set up the test framework and added a code coverage tool that throws an error if code coverage is not 100%. I then setup a simple continuous delivery pipeline using GitHub, CircleCi and Heroku. Every check-in to master is automatically tested and pushed to Heroku.

From day one, this setup forced our team to create automated tests for every line of code we write. These projects have never had code in them that is not executed at least once in automated testing. 100% code coverage has helped us build confidence in our ability to deploy new code often, sometimes multiple times a day. More importantly, it has allowed us to deliver more functionality, more quickly. It’s the only way I want to work now.

Confidence

The most important purpose of automated testing is to give us confidence. We want to have confidence that we can add new features quickly. Confidence that when we add a new feature, fix a bug, or refactor a module that we won’t break other functionality. Confidence that when others work in the code, they won’t break the existing features. Confidence that the project can stay in this state in perpetuity, always ready to ship, always ready to add the next feature, always ready to be improved.

Speed

Tests allow us to move faster. Some might argue that writing test slows you down. If all you measure is how fast one developer can get a feature out then yes, that’s true. But if you measure how fast multiple people can add new features to a product over months and years as the product grows and evolves, all while keeping quality high and not breaking production, automated tests allow you to move so much faster.

100% is Bare Minimum?

Some consider 100% crazy and a waste of time. I consider 100% the bare minimum. I actually want tests to be more than 100%, meaning that tests should execute parts of the code over and over again for different scenarios and configurations.

There’s something magical about 100%. It clearly states to anyone coming into the project that you simply cannot work in this project if you don’t write tests. I worked on a project where we set the limit to 95% early on in the project. That left this little bit of fudge factor. There was always room for an exception. And where there’s wriggle room, people will wriggle. So little bits of untested code kept getting into the project. Requiring 100% removes the exceptions and excuses.

Become a partner, not just a customer.
Connect with Kuali