Register to get access to free programming courses with interactive exercises

Code Coverage JS: Automated testing

As your project grows, it becomes tougher and tougher to determine which code has been tested and which hasn't, but it's still something you need to know. Issues knowing how much code has been tested usually arise when only part of the team is responsible for testing. The quality of the project can suffer.

Luckily enough, we can measure how much code has been tested via the code coverage metric. Coverage is analyzed by test frameworks that look at the connections between the lines involved in tests and all lines of source code. For instance, if tests do not cover a conditional construct, then all of the code within it is not tested.

In Jest, coverage is measured extremely simply. You just need to run tests with the --coverage flag:

npx jest --coverage

PASS  __tests__/half.test.js
 ✓ half (3ms)

File      |  % Stmts | % Branch |  % Funcs |  % Lines | Uncovered Line #s |
All files |    71.43 |      100 |    66.67 |    71.43 |                   |
 half.js  |       60 |      100 |       50 |       60 |             12,13 |
 index.js |      100 |      100 |      100 |      100 |                   |
Test Suites: 1 passed, 1 total
Tests:       1 passed, 1 total
Snapshots:   0 total
Time:        2.236s
Ran all test suites.

Once all the tests are done, Jest displays a summary table for each file. It shows the percentage of code covered by tests. In the example above, you can see the index.js 100% covered, but half.js is only 60% covered. The total code coverage is 71.43%. Note that coverage is highly dependent on which tests have been run. If some of them failed with errors, Jest will show much less coverage, since the tests just won't have reached all the code. That's why coverage is measured only when all the tests are green.

This metric help you find places that lack tests to add required ones. If there are initially no tests at all in the project, this metric will start to grow quickly. But then, as you get closer to 90 percent coverage, you have to fight for every line of code.

However, coverage alone does not guarantee that the covered code works correctly everywhere. Logical errors in the code cannot be caught by coverage alone. You need to test the same features, but with different sets of data. These are usually tests for borderline cases. There's a piece of good development practice: before fixing bugs, you should first write tests that reproduce them, and only after can you fix them.

What kind of coverage is considered acceptable? 100% coverage looks beautiful, but it's incredibly difficult to achieve. And for most projects, it makes no sense. The effort you spend on it won't pay off. Most developers agree that 80% is good enough coverage. You can usually stop there.

Do it yourself

  1. Clone the nodejs-package repository
  2. Run the tests, check their output
  3. Add --coverage flag to your tests, see how the output changes

Hexlet Experts

Are there any more questions? Ask them in the Discussion section.

The Hexlet support team or other students will answer you.

About Hexlet learning process

For full access to the course you need a professional subscription.

A professional subscription will give you full access to all Hexlet courses, projects and lifetime access to the theory of lessons learned. You can cancel your subscription at any time.

Get access
hours of theory

Sign up

Programming courses for beginners and experienced developers. Start training for free

  • 130 courses, 2000+ hours of theory
  • 1000 practical tasks in a browser
  • 360 000 students
By sending this form, you agree to our Personal Policy and Service Conditions

Our graduates work in companies:

<span class="translation_missing" title="translation missing:">Bookmate</span>
<span class="translation_missing" title="translation missing:">Healthsamurai</span>
<span class="translation_missing" title="translation missing:">Dualboot</span>
<span class="translation_missing" title="translation missing:">Abbyy</span>
Suggested learning programs
Development of front-end components for web applications
10 months
from scratch
Start at any time

Use Hexlet to the fullest extent!

  • Ask questions about the lesson
  • Test your knowledge in quizzes
  • Practice in your browser
  • Track your progress

Sign up or sign in

By sending this form, you agree to our Personal Policy and Service Conditions
Toto Image

Ask questions if you want to discuss a theory or an exercise. Hexlet Support Team and experienced community members can help find answers and solve a problem.