DEV Community

loading...
Cover image for Jest code coverage report explained

Jest code coverage report explained

Emma Goto 🍙
Front-end developer. In my spare time I like to make Trello Power-Ups ✨
Originally published at emgoto.com on ・2 min read

Your app's code coverage is what percentage of the code is currently covered by unit tests. In this post I will explain how we can generate a code coverage report with Jest.

Calculating your code coverage in Jest

Seeing your code coverage can be as simple as adding the --coverage flag when running your Jest unit tests:

yarn test folder/name --coverage
Enter fullscreen mode Exit fullscreen mode

After you run the coverage command you’ll get a summary report that looks like this:

Code coverage result in your terminal

Understanding the code coverage report

When looking at the summary table, it can be very hard to determine where you are missing coverage!

A much easier way is to create a visual code coverage report:

yarn test folder/name --coverage --coverageDirectory='coverage'
Enter fullscreen mode Exit fullscreen mode

This command will generate an HTML report in the folder you specified with --coverageDirectory. If you open up the index.html file in your browser, you will see lines highlighted in red. These are the lines that are not currently covered by your unit tests.

Code coverage report viewed in a web browser

How to track untested files with Jest's code coverage report

By default, Jest will calculate coverage for each file that has a test (and any files that they are importing).

This means that if you had the following files:

  • Foo.js
  • Foo.test.js (tests the code from Foo.js)
  • Bar.js

Even though Bar.js doesn't have any unit tests, this won't decrease the code coverage.
Jest will report that you have 100% code coverage!

By adding --collectCoverageFrom, Jest will calculate code coverage for all the files that you specify. Even ones without any tests.

yarn test folder/name --coverage --collectCoverageFrom='folder/name/**/*.js'
Enter fullscreen mode Exit fullscreen mode

The pitfalls of aiming for 100% coverage

As you increase your code coverage, sometimes it will be too hard to cover certain lines of code with unit tests. Spending your time trying to find a workaround to cover that line of code is never worth it. There are much better things you could be spending your time on than striving for 100% coverage!

Even if you do "cover" a line of code, there's no guarantee that it will be perfect and bug-free, either. If we take a look at a double function that doubles the number you pass in:

const double = (number) => 2;
Enter fullscreen mode Exit fullscreen mode

You could test that double(1) = 2 and that test would pass. You would have 100% code coverage as well. But your function would fail with all other numbers.

Code coverage is useful, but it's important not to use it as the only metric to measure your unit tests. Make sure to keep in mind all the possible edge cases and different scenarios, as code coverage won't pick these up.

Discussion (4)

Collapse
diass_le profile image
Leonardo Dias

Nice post!

I really enjoy Jest coverage, but... My problem's with testing private functions/ not exported functions using libs like rewire to get these functions from the module/class. We can test well and Jest assertions work fine, but coverage not. The Jest Coverage just ignore these tests :/

Collapse
emma profile image
Emma Goto 🍙 Author

Interesting! I hadn't heard of rewire before. Looks like there's an open issue on their repo for jest coverage but no solution yet 😓

Collapse
vaibhavkhulbe profile image
Vaibhav Khulbe

I like how easy it is to test your components with Jest!

Collapse
emma profile image
Emma Goto 🍙 Author

Yes! I've never had the chance to use react-testing-library but I've heard good things about that one as well.