Decide whether a run's tests actually executed the code it changed.
A green test suite proves a test exists, not that it covers the change: a test written for a private helper passes while the feature it was meant to cover is never executed at all.
Why zero, and never a threshold
Percentages lie for declarative code: a module whose body is compile-time DSL reports full coverage merely for being loaded, while a module full of real branches reports a low number for being partly tested. A threshold is therefore both unfair to the first and meaningless for the second. "Never executed at all" is the only claim a coverage table supports unambiguously.
Scope
The parser targets the NN.NN% | Module.Name table that mix test --cover
prints, read out of a worker's report rather than run by the harness (tools
execute commands; the harness only sees their output). Projects in other
ecosystems simply produce no parseable data — reported as :no_data, which
callers should treat as "ask for coverage", not "fail".
Summary
Functions
Modules a source file defines, in source order.
Module-name => percentage, parsed from a coverage table anywhere in text.
Which of changed_files no test executed, given a worker's transcript.
Functions
Modules a source file defines, in source order.
Module-name => percentage, parsed from a coverage table anywhere in text.
The Total row is dropped: it is a summary, not a module.
Which of changed_files no test executed, given a worker's transcript.
Returns :no_data when the transcript carries no coverage table at all —
the caller cannot conclude anything, and should ask for one rather than
treat silence as failure. Files defining no module (assets, config) are
skipped: coverage has nothing to say about them.
A module absent from the report counts as unexercised — it was never even loaded.