Increasing Unit Test Coverage with jest-it-up

Incrementally improving team code coverage with minimal policing

Unit testing is an integral part of writing and maintaining high-quality code. Code coverage is a way of measuring how much of the code is being tested, or covered, when running the tests. As a general rule of thumb, 80% or higher code coverage is a good target to aim for and indicates a healthy level of unit testing.

Jest is a popular testing framework for JavaScript projects. To enforce a minimum level of code coverage in Jest, use the coverage threshold configuration. After configuring a threshold value, Jest will fail the build if a developer adds new code to the project without adequate unit tests. Typical project setups won’t allow developers to merge their changes into the main branch of code if there is a failing step in the build pipeline. Thus a coverage threshold that has not been met automatically directs the developer to add more unit tests in order to proceed.

Setting a minimum threshold of 80% is great for new projects or projects that already have the desired level of code coverage. For projects where the coverage levels are lower than desired, often times it’s better to gradually increase coverage rather than dedicating several sprints just to writing more tests. We want a way to encourage the team to gradually increase coverage until the desired level is reached.

On a recent project we used a tool called jest-it-up to do just that. This simple utility updates the Jest coverage thresholds to match the current coverage values. If the test run was successful, it means that the previous thresholds were met, so the new coverage values must be equal to or greater than the current thresholds. Running jest-it-up sets the coverage thresholds to these new values. This results in small incremental increases of our coverage thresholds.

We chose to run jest-it-up as part of our build pipeline only on main branch builds. When a pull request (PR) build runs, it will fail if the unit test coverage thresholds are not met. Thus if a PR is merged to the main branch that means that its coverage values must meet or exceed the current thresholds. After running unit tests on the main branch, the pipeline automatically runs jest-it-up to update the thresholds with the new higher coverage values and commits the new jest config. Once that completes any future PR must meet the new slightly higher threshold.

The chart below shows the results of adding jest-it-up to a real world project. We can see how the coverage values slowly increase over time. Line and statement coverage went from about 60% to around 90%. This change happened organically in the team without much policing.

If you look closely at the graph above you may notice a few small dips in coverage values. This occurs when a developer lowers the coverage threshold values in the jest.config file directly as part of their PR. While this practice is not encouraged and easily detected as part of code reviews, it’s important to have this escape hatch if needed. Sometimes there is deadline pressure or a hot fix needs to go out right away and we can temporarily bend, intentionally introducing some technical debt, to meet the immediate need.

Encouraging and enforcing code coverage minimums can be a good way of promoting a culture of unit testing within your project team. If you’re looking for a way to improve the code coverage of your project incrementally, give this technique a shot and see what happens.