Work out statement, decision, function, condition and MC/DC coverage, check them against published requirements, and catch reports that cannot be true.
The three figures jest, pytest-cov, JaCoCo, lcov and SonarQube all report. Enter whichever you have — one is enough.
Reported by tools built for certification work (VectorCAST, LDRA, Rapita, BullseyeCoverage). Leave blank if your tool does not measure them.
Definitions of decision coverage and MC/DC are quoted from NASA's Software Engineering Handbook, section 7.21.
| Criterion | What it requires | Reported by |
|---|---|---|
| Statement coverage | Every executable statement runs at least once. | Every mainstream tool |
| Decision coverage | "Every entry and exit point in the program has been invoked at least once, and every decision in the program has taken all possible outcomes at least once." Also called branch coverage. | Every mainstream tool |
| Function coverage | Every function or method is called at least once. Says nothing about what happens inside it. | Most mainstream tools |
| Condition coverage | Every boolean sub-expression takes both values — with no requirement that any of them changes the outcome. This is the criterion most often mistaken for MC/DC. | Some tools; often mislabelled |
| MC/DC | "Every entry and exit point in the program has been invoked at least once. Every condition in a decision in the program has taken all possible outcomes at least once, and each condition has been shown to affect that decision outcome independently." | Certification tools only |
Each of these ties structural coverage to a criticality level, and each is sold rather than published. We will not print a percentage we cannot show you the source for — read the standard, or ask your certification authority.
| Standard | Domain | What it ties coverage to |
|---|---|---|
| DO-178C / ED-12C | Airborne software | Structural coverage obligations to software level (A–E). Sold by RTCA; the level determines which criterion applies, and Level A is where MC/DC enters. |
| ISO 26262 | Road vehicles | Structural coverage recommendations to ASIL (A–D), at unit and integration level. Sold by ISO. |
| IEC 62304 | Medical device software | Verification rigour to software safety class (A–C). Sold by IEC. |
Coverage percentages describe test execution, not correctness or safety. Requirement thresholds shown here are quoted from the sources named; they are not certification advice, and the standard or authority governing your project is the only binding reference.
You might also find these calculators useful
Paste your code and get its cyclomatic complexity, function by function
Count SLOC, comments and blanks from pasted code, then estimate effort
Measure DevOps performance with four key metrics
Paste code, get its time and space Big-O with the derivation
Enter covered and total counts for any of statement, decision, function, condition or MC/DC coverage. You get each percentage, a comparison against requirements whose thresholds are actually published, and a check on whether your figures can all be true at once. Standards that govern coverage without publishing a number are named rather than guessed at.
Code coverage is the share of some countable thing in your program — statements, decisions, conditions — that your tests executed at least once. It is a family of criteria, not one number, and the criteria are ordered by strength: satisfying MC/DC in full means decision coverage is also satisfied in full, which in turn means statement coverage is. That ordering is the useful part, because it means a report claiming 100% of a strong criterion alongside less than 100% of a weaker one is internally impossible.
Coverage for any one criterion
Work out whether you have the criterion the standard actually asks for, rather than the one your CI happens to print.
When two figures cannot both be true, the cause is nearly always a scope or filter difference between runs. The impossibility check names it.
Decide which criterion your gate measures and whether it applies to new code or all code, using SonarQube's published default as a reference point rather than a rumour.
A suite with no assertions can reach 100% statement coverage. Showing the criteria side by side makes the difference between execution and verification concrete.
"87% coverage" is not a fact until you know 87% of what. Statement coverage and MC/DC on the same suite can differ by tens of points, and only one of them is what a safety standard asks for.
NASA's handbook states 100% MC/DC for safety-critical components. Nothing comparable is published for statement coverage, so a statement figure cannot answer that question however high it is.
Coverage criteria subsume one another, so some combinations of figures are impossible. A report showing 100% MC/DC and 92% decision coverage means the two numbers came from different runs, scopes or filters.
SonarQube's default 80% applies to new code only, and is skipped under 20 new lines. Held against a whole codebase it is a much harder target than the gate it came from.
Divide the covered items by the total items for one criterion and multiply by 100. The arithmetic is trivial; the substance is in which criterion you counted. Statement, decision, function, condition and MC/DC each count a different thing, so each gives a different percentage for the same test suite.
There is no published universal figure, and this page will not invent one. The two thresholds we can cite are SonarQube's default gate — 80% on new code, skipped under 20 new lines to cover — and NASA SWE-219's 100% MC/DC for safety-critical components. Anything presented as an industry-standard 70% or 80% overall target is convention, not a published requirement.
MC/DC requires that every condition in a decision take both values and that each condition be shown to affect the decision's outcome independently. Condition coverage requires only the first half. That independence requirement is the whole difference, and it is why condition coverage is not a substitute when a standard asks for MC/DC. NASA's handbook puts it plainly: the MC/DC criterion is much stronger than condition/decision coverage.
DO-178C ties structural coverage obligations to the software level, and which criterion applies depends on that level — MC/DC enters at Level A. We do not publish per-level percentages here because DO-178C is sold by RTCA rather than published, so we cannot show you the text a figure came from. Read the standard, or ask your certification authority. The same applies to ISO 26262 and IEC 62304.
For partial coverage that is possible, because the two have different denominators: MC/DC counts condition/decision obligations while decision coverage counts decision outcomes. A suite that fully covers one complex decision and never reaches a simple one can score higher on MC/DC. Only the 100% case is a contradiction — full MC/DC entails full decision coverage.
Outside safety-critical work, usually not. Coverage measures execution, not verification: a test suite with no assertions can execute every line. The last few percent tend to be error handling that is expensive to reach and rarely where defects hide. Where a standard requires 100% of a specific criterion, that is a compliance obligation rather than a quality argument.
Yes, if the new tests bring previously unmeasured files into scope, or if you add code alongside them. This is also the most common reason two figures in one report disagree in impossible ways — they were measured over different sets of files.
Tools aimed at certification work: VectorCAST, LDRA, Rapita and BullseyeCoverage among them. Mainstream tools such as jest, pytest-cov, JaCoCo and lcov report statement, branch and function coverage but not MC/DC, which is why a project that needs it usually needs a second tool rather than a configuration change.