Skip to main content
Function coverage counts functions executed at least once, out of the functions the report recorded. It is the coarsest dimension in the family — a function counts as covered the moment one test touches its first line — and that coarseness is its value: a function at zero is a complete blind spot, not a partially-tested one, and a file where half the functions never run tells a different story than a file where every function runs halfway. Crap4j, the original CRAP implementation, operated at exactly this granularity for the same reason: functions and methods are the unit developers reason about, test, and refactor.

​
What mehen emits

Published on the file’s root space (file-level totals from the report’s own function records). Absent when the format records no functions — a Go coverprofile has none, and Clover only knows the method lines its instrumenter marked.

​
Where the records come from

Note the subtle relationship with the per-function line coverage mehen also publishes: the file-level coverage.function above comes from the report’s own records, while each function space in the metric tree carries coverage.line/coverage.branch computed from mehen’s own parse of the function’s line span. The two views agree on what “untested function” means but serve different queries — “how many of this file’s functions run at all?” versus “how covered is this function?”. The per-space values are the ones the CRAP composite will consume, because they exist even for formats without function records.

​
How to read it

​
Gating

Function coverage makes a forgiving first gate for legacy codebases: it demands some test reaches each function without dictating depth, and it is cheap to satisfy incrementally — one test per blind spot.

​
See also

  • Line coverage — depth within the functions this metric counts.
  • Branch coverage — outcome-level depth.
  • NOM — how many functions a file defines in the first place.

​
References