Skip to main content
Line coverage is the fraction of instrumentable lines executed at least once while the test suite ran. It is the lingua franca of coverage — every supported format measures it, every coverage service reports it — and the weakest claim in the family: an executed line proves the tests reached the code, not that they asserted anything about it. Read it as a risk denominator: low coverage marks code where the suite can catch nothing at all.

​
What mehen emits

Published on the file’s root space and, span-scoped, on every function and closure space in the metric tree — the per-function values are what make the numbers actionable (and what the planned CRAP composite consumes).

​
Semantics

  • Instrumentable lines only. The denominator is the lines the coverage tool instrumented — blank lines, comments, and non-executable declarations are excluded by the producing tool, not by mehen. LCOV DA records with negative counts (non-instrumentable markers some instrumenters emit) are dropped.
  • Hit means hit at least once. Execution counts are preserved internally (and used for max-merging), but the rate counts a line as covered at any count ≥ 1 — matching how every producing tool defines the percentage.
  • Statements fold to lines. Istanbul statement maps and Go basic blocks resolve to line numbers; multiple statements on one line keep the maximum count.
  • Unmeasured ≠ 0%. A file absent from every report, or a function span containing no instrumented lines (macro-generated code, #[cfg(test)] items, dead-code-eliminated functions), publishes nothing. Only genuinely instrumented-but-unexecuted code reads 0.
  • Per-function attribution is line-range based. A function space spanning lines 10–24 aggregates the report’s records for those lines. Line ranges come from mehen’s real parsers, so the attribution is exact for the function body; a multi-line signature counts from the declaration line the parser assigns.

​
How to read it

Google’s large-scale guidance is a useful calibration: they characterize 60% as acceptable, 75% as commendable, and 90% as exemplary — while explicitly warning against chasing the number for its own sake, because the marginal lines are usually the least valuable to cover. The empirical literature agrees from the other side: Inozemtseva & Holmes found coverage only weakly-to- moderately correlated with suite effectiveness once suite size is controlled, so a high percentage must never be read as proof of a strong suite.

​
Gating

A configured coverage.line threshold is itself the trigger for report ingestion — no flag needed in CI. Unmeasured files skip the gate (never a fabricated violation); genuinely 0%-covered files fail it.

​
See also

​
References