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
- Clone the nodejs-package repository
- Run the tests, check their output
- Add
--coverageflag to your tests, see how the output changes
Are there any more questions? Ask them in the Discussion section.
The Hexlet support team or other students will answer you.
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.
