Test Coverage: How Much Is Enough?

Why the percentage lies

Coverage measures which code executed, not whether you checked the result. That gap is everything.

This test calls discount, so the function shows as 100% covered. It asserts nothing. It would pass if discount returned a string, threw away the input, or formatted your hard drive. A coverage report rewards it exactly the same as a test with five real assertions. High coverage with weak assertions is more dangerous than low coverage, because it looks like safety.

The second trap is chasing the last few percent. Going from 0 to 70% covers the code that runs on every request. Going from 95 to 100% usually means testing defensive branches that can't happen, error handlers for impossible states, and trivial accessors. The effort curve goes vertical while the value goes flat. This is the same diminishing-returns logic behind the testing discipline in the five pillars of modern software delivery: tests exist to let you ship faster with confidence, not to satisfy a dashboard.

Measuring it in Node

You don't need a dependency. The built-in runner reports coverage directly.

That prints a per-file table of line, branch, and function percentages with the uncovered line numbers. For a nicer HTML report or finer control, c8 reads the same V8 data.

Read the report by branches, not lines. A file at 95% lines but 60% branches is hiding untested logic in its conditionals, and that's where you should spend the next hour.

Picking a threshold

A healthy target for most application code is roughly 80% lines and 70% branches, enforced as a floor rather than a goal. The point of the floor is to stop coverage from silently rotting as the codebase grows, not to force every file to the same number.

With check-coverage, c8 exits non-zero when coverage drops below the floor, which turns it into a real gate.

Wire that into CI and a pull request that drops coverage below the line fails before it merges. Pair it with a required status check and the rule enforces itself without anyone policing it in review.

Where to actually spend your tests

Not all code deserves the same scrutiny. Push for high branch coverage on the parts where a mistake is expensive: pricing and money math, authorization checks, data validation, anything that writes to the database, and the error paths your users hit when something upstream fails. These are the branches worth testing twice.

Relax on the rest. Configuration loading, thin controllers that just forward to a service, generated code, and one-line accessors don't earn the maintenance cost of dedicated tests. If you exclude them, do it explicitly so the exclusion is visible and reviewed.

A team that measures branch coverage on its core logic and enforces a sane floor in CI gets the real benefit of coverage: a fast warning when a risky path goes untested. Treat the number as a smoke detector, not a scoreboard, and it'll earn its place in your pipeline.