Use coverage as a map

Coverage says which code executed during tests. It does not say that assertions were useful or requirements were correct.

Branch coverage is valuable for validation and error handling because one executed line can contain several outcomes. Inspect uncovered areas, add tests for meaningful risk, and exclude generated code only with a documented reason.

node --test --experimental-test-coverage

Suppose a route contains this decision:

if (!book) return json({ code: 'not-found' }, 404)
return json(book, 200)

A happy-path test may execute the function and most of its lines while never proving the missing-book branch. Branch coverage points to that gap. The next question is not “How do I color the line green?” but “What user-visible failure is untested?” Send a request for an absent ID and assert the 404 contract.

Coverage also allows false confidence. A test can execute both branches and contain no meaningful assertion. One quick audit is mutation: temporarily change 404 to 200 or reverse the condition. If the suite stays green, execution was measured but behavior was not protected.

Do not chase one universal percentage. A parser with many decisions may deserve dense branch coverage; a thin adapter may be better protected by a few real integration cases. Use thresholds to prevent accidental large regressions only after the baseline is understood. Exclude generated or unreachable platform code with a written reason so the report remains honest.

Run coverage, choose one untested error branch, and add a behavior-focused test for it. Mutate the branch afterward and confirm the new test fails for the expected public outcome.