Test coverage

Execution is only part of a test

A test can execute a line without checking whether it produces the right result. Coverage therefore shows where execution happened, not whether the assertions were strong enough to catch a defect.

Branch coverage can reveal paths that line coverage misses. For example, a line containing a conditional expression might execute while one of its outcomes is never exercised. Neither measure automatically tells you whether the requirements themselves are correct.

A small example

Consider an illustrative function that applies a discount to an order. A test calls the function with a normal basket and checks only that the result is a number. The implementation runs, and its lines may appear covered.

That test could still pass if the discount were applied twice. A better test checks the expected total and adds cases for the relevant boundaries, such as a basket just below the eligibility threshold.

The improvement comes from checking behavior, not from changing the percentage.

Use coverage to ask better questions

Review the uncovered code in a proposed change. Is it an important error path, a hard-to-reach fallback, or generated code that should be excluded from the report? The answer determines what to do next.

Avoid a universal percentage that treats every module as equally risky. Agree on exclusions and the coverage type, then inspect the cases that matter. A smaller set of meaningful tests can provide more confidence than a large suite that executes code without challenging its assumptions.