Statement Coverage

Why it matters

A defect can only cause a failure when the code containing it runs. Statement coverage points at code that no test has ever executed, where a defect cannot show up in those tests. It is also the simplest coverage measure to explain.

Its weakness matters as much. 100% can be reached with very few tests that leave decision outcomes, loop cases and data values untested; branch coverage, the subject of the next lesson, is a stronger criterion. A tester who knows exactly what it proves can use it to find gaps without treating it as proof of good testing.

What statement coverage measures

In the ISTQB Foundation syllabus v4.0, statement coverage is measured as the number of executable statements exercised by the tests divided by the total number of executable statements, as a percentage: statement coverage = statements executed / executable statements × 100%.

An executable statement is one that performs an action when the program runs. Each statement counts once, however many tests run it and however often a loop repeats it. At 100%, every executable statement has run at least once, so a statement containing a defect has run too, which may cause a failure that reveals it. "May" is the key word, as the worked example shows.

• Count: assignments and declarations with a value (let fee = 5;), calls, return and throw, and each if, switch or loop statement itself: evaluating its condition is an action.
• Do not count when you work by hand: comments, blank lines, lines holding only a brace, a function's signature, or type-only code such as a TypeScript interface.
• A statement is covered when at least one test executed it, whether or not that test passed or asserted anything.
• Tools differ in the details: coverage.py records executed lines, and a Python def line runs when the module is imported, so it counts as covered even if no test calls the function. Compare percentages only from the same tool, settings and files.

Worked example: a parking fee function

Requirement: "Parking is free for the first 30 minutes. After that, every started hour costs 5.00 SAR. Members pay half." The developer wrote the function and two unit tests; Math.ceil on line 4 rounds up, which implements "every started hour". Its executable statements are lines 2, 3, 4, 6, 7 and 9; the signature and the closing-brace lines are not statements.

 1  function parkingFee(minutes, member) {
 2    Part 1:1let fee = 5;
 3    Part 2:2if (minutes > 30) {
 4      Part 3:3fee = Math.ceil((minutes - 30) / 60) * 5;
 5    }
 6    Part 4:4if (member) {
 7      Part 5:5fee = fee / 2;
 8    }
 9    Part 6:6return fee;
10  }

Executable statements: lines 2, 3, 4, 6, 7, 9 (6 in total)

Unit test                  Expected  Actual  Result  Lines run      Statement coverage
T1  parkingFee(90, false)  5         5       passed  2 3 4 6 9      5/6   83%
T2  parkingFee(200, true)  7.5       7.5     passed  2 3 4 6 7 9    6/6  100%
T1 + T2                                              2 3 4 6 7 9    6/6  100%

• T1 parkingFee(90, false) runs lines 2, 3, 4, 6 and 9 and returns the expected 5. Line 7 does not run because member is false: 5 / 6 = 83%.
• T2 parkingFee(200, true) runs all six: 170 minutes after the free period are 3 started hours, 15.00 SAR, halved to 7.50. Together T1 and T2 reach 6 / 6 = 100%, and T2 alone would too.
• A test from the requirement's first sentence, T3 parkingFee(20, false), expects 0 and gets 5: line 2 starts the fee at 5 instead of 0, so the free period is charged.
• Line 2 ran in both T1 and T2, yet neither failed: line 4 overwrote the wrong value each time. The defect shows only when minutes > 30 is false, an outcome with no statement of its own, so statement coverage never asked for it. Branch coverage, in the next lesson, does.

 1  function parkingFee(minutes, member) {
 2    let fee = 5;
 3    if (minutes > 30) {
 4      fee = Math.ceil((minutes - 30) / 60) * 5;
 5    }
 6    if (member) {
 7      fee = fee / 2;
 8    }
 9    return fee;
10  }

Executable statements: lines 2, 3, 4, 6, 7, 9 (6 in total)

Unit test                  Expected  Actual  Result  Lines run      Statement coverage
T1  parkingFee(90, false)  5         5       passed  2 3 4 6 9      5/6   83%
T2  parkingFee(200, true)  7.5       7.5     passed  2 3 4 6 7 9    6/6  100%
T1 + T2                                              2 3 4 6 7 9    6/6  100%

What 100% statement coverage does not prove

The ISTQB syllabus names two limits: executing a statement does not detect every defect in it, such as a data-dependent one, and 100% statement coverage does not ensure that all the decision logic has been tested. They appear in recurring shapes:

• Missing outcomes: an if without an else has a false outcome with no statement of its own. The parking defect lives there.
• Data-dependent defects: average = total / count runs without a failure when count is 3, and fails or returns a meaningless value when it is 0. The statement is covered either way.
• Loops: one pass through a simple loop body covers every statement in it. Zero passes (an empty list) and many passes are never required.
• Compound conditions: if (gold || total >= 200) is one statement, covered by a test where gold is true, and in most languages the second condition is then not even evaluated. The lesson on condition coverage returns to this.

Using statement coverage well

Statement coverage is most useful as a floor: a statement that no test runs is a certain blind spot. It is least useful as a goal, because the cheapest way to raise it is a test that runs code and checks little.

• Start from requirement-based tests (equivalence partitioning, boundary value analysis), measure, and only then add tests for statements that never ran. Partitioning the parking minutes into "up to 30" and "over 30" produces T3, which no coverage report asked for.
• When a statement cannot be reached in a test environment, teams can exclude it explicitly, as with coverage.py's # pragma: no cover or Istanbul's /* istanbul ignore next */. Review every exclusion: excluded code is no longer measured at all.

Try it: Equivalence Partition Generator Try it: Boundary Value Generator

Frequently asked questions

References

• ISTQB Certified Tester Foundation Level (CTFL) v4.0ISTQB · 2023The foundation syllabus of software testing: test levels and types, test design techniques, test management and tools.
• ISTQB GlossaryISTQBThe standard definitions of testing terms — test case, regression testing, severity, priority, boundary value analysis and the rest.
• NIST SP 500-235: Structured Testing: A Testing Methodology Using the Cyclomatic Complexity MetricNIST · 1996Structured (basis path) testing: McCabe's cyclomatic complexity used to derive a basis set of independent paths to test — more thorough than statement and branch coverage.