Why coverage is not enough

You have a passing suite. The natural next question a team asks is: "how much of the code is tested?" The usual answer is code coverage.

Measuring coverage

Run the coverage script:

npm run test:coverage

You will see a coverage table, and here is the surprising part: both src/leapYear.js and src/discount.js report 100% on every column, statements, branches, functions, and lines.

By the coverage numbers alone, the two modules are indistinguishable. Both look perfectly tested.

What coverage actually measures

Code coverage answers a single, mechanical question:

Was this line executed while the tests ran?

That is genuinely useful. Coverage finds code that no test touches at all, and that is worth knowing.

But notice what coverage does not ask:

Was the result of that line ever verified?

A test can execute a line and then assert nothing meaningful about it. A test can run a branch at a safe value but never at the boundary where a bug hides. In both cases the line is green on the coverage report, and a real defect can sit right underneath it.

👨‍🏫 This is the central idea of the whole course. Coverage measures execution. It does not measure verification. Two suites with identical 100% coverage can have wildly different abilities to catch bugs.

The gap, made concrete

The discount.js module has three business-rule boundaries and one error message. Its tests run every line, so coverage is 100%. Yet, as you will see, four small changes to that code go completely unnoticed by the tests. The coverage badge stays green while the behavior silently breaks.

What we need is a way to measure the assertions, not the execution. That measurement is called mutation testing, and you will run it in the next lesson.

Commands overview 📖

npm run test:coverage

Runs the Jest suite and reports how much of the source code was executed by the tests.

Syntax:

npm run test:coverage

Example:

npm run test:coverage

Suggested content 📚

• Jest - Configuring code coverage
• What is mutation testing? - Stryker documentation

Exercise 🎯

Run npm run test:coverage and read the table. Confirm that both modules report 100% coverage.

Then open src/discount.test.js and, just by reading, try to spot a business rule that is executed but never asserted at its exact boundary. Write down your guess. You will check it against Stryker's report soon.

🙊 The four weak spots are the boundaries total < 0, total >= 100, and price < 50, plus the error message thrown for a negative total. Do not worry if you did not catch them all by eye, that is precisely the point.

Show the world what you learned 🌎

To show your professional network what you learned in this lesson, post the following on LinkedIn.

I am taking the "Mutation Testing with Jest and Stryker" course by @Walmyr Lima e Silva Filho at the @Talking About Testing school, where I learned that code coverage measures whether a line was executed, not whether its behavior was verified. #TalkingAboutTesting #TATSchool #MutationTesting #Testing

👨‍🏫 Remember to tag me in your post. Here is my LinkedIn profile.