Track project code coverage with Jest
Jest comes pre-packaged with the ability to track code coverage for the modules you're testing, but it takes a little extra work to make it track untested files as well. Let's look at what Jest can do for you, what you have to do yourself, and how to setup code coverage thresholds so you can work to improving the code coverage numbers for your projects.
[00:00] To track code coverage for our project with Jest, we simply specify the command line flag of --coverage with our test command. Now, if we run npm t to run our test script, we'll see a coverage report output in our console. There's new coverage folder which we can open in our browser to explore the coverage report of a project.
[00:17] Here, we see a listing of all the files in our project that were instrumented for coverage. While it appears that we have 100 percent code coverage for the project, you'll notice that we are missing code coverage for the subtract module here.
[00:29] Jest will only instrument files for coverage if they have been required while our tests are running and, because the subtract module isn't being required in our test, it's not getting instrumented for coverage and is therefore excluded in our coverage report.
[00:41] Let's go ahead, import it into our sum test, and see how that affects our coverage numbers. You'll see that it's now included in their coverage report. Let's say that we're adding Jest to an existing project. It would get really tedious to add imports for every file by hand to get a more accurate measure of code coverage for the project.
[00:59] Instead, we're going to do this dynamically. Let's remove that import here. Now, let's go to our package.json where we can configure Jest to instrument files for coverage even if they're not imported in our test. We'll do this by adding a new property called collectCoverageFrom. This is an array of globs.
[01:16] For us, we can simply specify the glob src/*.js. Now, if we run npm t, we'll see that Jest instruments that file for coverage even though it's not explicitly included our test. Finally, as we work our way to better code coverage in our project, we can configure Jest with a coverage threshold.
[01:34] This means that if our code coverage ever drops below a specified percentage, our test script is going to fail. That way we can encourage ourselves and other developers on the project to continue adding tests as they add code.
[01:46] To do this, we're going to specify a coverageThreshold property in our Jest configuration. In here, we'll specify a global object and indicate the coverage thresholds for branches, functions, lines, and statements. We'll put 100 percent for each of them now and see what happens to our test script with that.
[02:04] If we run our test script, we'll see that Jest is complaining about our coverage levels for statements, lines, and functions not meeting the global threshold. We'll go ahead, update our global threshold, and run our test script again. This time, everything passes with flying colors.
[02:18] In review, to track code coverage for our project, we simply add a --coverage flag to our test script. Then we configure Jest to include our non-tested files in the code coverage report by specifying a glob of the files we want to match.
[02:31] Note that this is excluding our test files for us automatically. Even though sum.test.js actually matches the glob src/*.js, Jest is automatically excluding that test file because we don't want the code coverage stats of our test files loading our project coverage numbers.
[02:48] Finally, we can configure Jest to have a threshold so we don't drop below our current code coverage. We can work toward better coverage in the future. One other thing we'll go ahead and add is the coverage directory to our gitignore file so we don't commit this generated report to search control.
[03:04] That's how you track code coverage for your projects with Jest.