Home/ Techniques/ Junior/ Statement Coverage
Junior · White Box Technique

Statement Coverage

Look inside the box. Statement Coverage is the most basic way to answer the question: "Have we actually run every single line of code in our test suite?"

Junior ISTQB CTFL 4.3.1 — K2 Understand ~10 min read + exercise

1 The Hook — The "Never Seen" Code

Imagine a builder who builds a house but never checks if the light in the attic works. They've tested the kitchen, the bathrooms, and the bedrooms, but the attic light has never been turned on.

In software, developers often write "Error Handlers" or "Cleanup Code" that only runs in rare situations. If you never test those situations, that code has 0% coverage. It could be broken, missing a semicolon, or formatted wrong, and you'd never know until it crashes in production. Statement Coverage ensures every light in the "house" is turned on at least once.

2 The Rule — The Math of Coverage

Coverage % = (Number of Statements Executed ÷ Total Number of Statements) × 100

If your code has 10 lines (statements) and your test hits 8 of them, you have 80% Statement Coverage. To reach 100%, you must find a test case that triggers those last 2 lines.

3 The Analogy — The Covid Tracker

Analogy

Scanning every seat in the Stadium.

Think back to the NZ Covid Tracker app. If you go to a stadium with 30,000 seats, "Statement Coverage" is like making sure every single seat has been sat in at least once by at least one person over the course of the season. It doesn't mean every seat was sat in by the right person, or that people sat in them at the same time. It just means no seat was left untouched.

4 Watch Me Do It — Calculating GST

Scenario: You're testing a simple function that adds GST (15%) to a price.

JS Function: applyGST(price, isExempt)
function applyGST(price, isExempt) {
  if (isExempt) {             // S1
    return price;             // S2
  }
  let total = price * 1.15;   // S3
  return total;               // S4
}
  • Test Case 1: price=100, isExempt=true.
    Hits: S1, S2. (S3 and S4 are skipped). Coverage: 2/4 = 50%.
  • Test Case 2: price=100, isExempt=false.
    Hits: S1, S3, S4. (S2 is skipped). Coverage: 3/4 = 75%.
  • Combined: Running both tests hits S1, S2, S3, and S4. Combined Coverage: 100%.

5 Decision Tool — When is 100% enough?

Statement coverage is a floor, not a ceiling. It's the minimum bar.

✅ High Coverage is good for...

  • Ensuring there is no "Dead Code."
  • Catching simple syntax errors in rare paths.
  • Building confidence in new developers.

--ink-2 Coverage is NOT proof of...

  • Logical correctness.
  • Security.
  • Performance.

6 Common Mistakes

🚫 Thinking 100% Coverage = Zero Bugs

I used to think: If I hit every line, the code must be perfect.
Actually: You can hit a line of code with the "wrong" data and it still passes. Statement coverage only tells you the line was executed, not that it worked.

🚫 Ignoring "If" logic

I used to think: I hit the 'if' line, so I'm done.
Actually: To get full coverage, you often need two tests for every if: one to go "In" and one to "Skip."

7 Now You Try — Calculate the Gap

🎯 Interactive Exercise

Scenario: You have a 10-line function. Your first test hits 6 lines. Your second test hits 8 lines (including 4 lines the first test already hit).

What is your Combined Statement Coverage?

Click to reveal math

Test 1 hits: 6 lines.
Test 2 hits: 4 new lines.
Total Unique Hits: 10 lines.
Coverage: 100%

8 Self-Check

Q1. Is Statement Coverage a Black Box or White Box technique?

It is a White Box (or Structure-based) technique because you have to look at the source code to calculate it.

Q2. Can you have 100% statement coverage but 0% branch coverage?

No. 100% statement coverage implies you've at least hit the 'True' side of every branch. However, you could have 100% statement coverage and only 50% branch coverage (if you never hit the 'False' side of an empty else).

9 Interview Prep

"Why is 100% statement coverage considered the 'absolute minimum'?"

Answer: "Because it simply proves that no part of the code is unreachable or unvisited. It doesn't account for complex logic, null pointers, or data-driven bugs. While 100% is a great metric to catch dead code, it's only the first step towards more robust techniques like Branch or Path coverage."