100% Automated Test Coverage is like stepping on every step on the way to the top. Photo by Jyoti Singh on Unsplash

The Problem With 100% Unit Test Coverage

The 100% Automated Test Coverage dilemma has no easy solution. This article discusses how 100% Unit Test Coverage can be misleading. There is a practical example, as well as suggestions to deal with this. Software quality has a lot of key stages which offer a lot of value. The article will stick to Automated Testing methods. However, manual testing and User Acceptance Testing are always valid suggestions for delivering quality software.

--

All the code can be found on Github.

The Code and the Unit Tests

The code shown in the Gists below (called moreCakes.test.js) is using Jest. They cover the example code (moreCakes.js), which uses NodeJS.

If you’re interested in playing around with this, the code is available here. The first example is in the master branch. The branch called extended-tests is the second example.

The file moreCakes.js exports a function called createMoreCakes which takes in some arguments; instructions, chocolateId and secretSauceList. The parameter secretSuaceList will be an array (…there is no validation to enforce this). Line 9 creates a for loop and iterates through the array, and doesn’t do anything important with sauce .

Attempting to reduce the coverage

The test called describe('When there are multiple secret sauces',(lines 43 to 56 of moreCakes.test.js) can be removed, then the coverage can be triggered…

--

--

Kris Raven

Quality Engineering Manager | A wholesome mix of QA, Automated Testing, music and philosophy | Enjoys unit tests | Favours integration tests