Foundations — Code coverage — line, branch, path coverage

Before you can read the parent note, you need to already own a small toolkit of ideas. The parent throws around words like executable line, decision, branch outcome, and path as if you already knew them. Here we build each one from nothing, in an order where every idea rests only on the ones before it — and we only reach symbols like the fraction bar, the "out of a hundred" sign, and the multiplying path count after the plain-word idea behind each is already yours.

0. What is a "program" made of? (the atom: the statement)

Before we count anything, we must agree on what the smallest countable piece is.

We care about statements because coverage's whole job is to ask: "which items on the to-do list did the finger actually touch?" If the finger never touched an item, you have no proof that item works.

Not every line is a statement we count, though. Blank lines and comments do nothing at runtime, so they are not executable. That word matters:

Why the topic needs this: the line-coverage formula divides by "total executable lines". If you counted comments, a perfect score would be impossible and the number would be meaningless.

1. The finger that moves: control flow

Look at the figure. On the left, the finger just walks straight down: statement 1, then 2, then 3. Boring and predictable — nothing to choose. On the right, the finger reaches a diamond and must pick one of two ways to go. That diamond is the single most important idea in this whole topic, so it gets its own name next.

The parent note is built on control flow because coverage is literally a record of where the finger went. This is also the bridge to the vault note Control Flow Graph, which draws these fingers-and-diamonds as a picture.

2. The fork in the road: the decision

The question itself — x > 50 — is called the condition. Its answer is either True or False, the two words that describe yes/no in programming. (These come from Unit Testing and everyday if logic; if you have ever written an if, you have met a decision.)

3. The two roads out of a fork: branch outcomes

Here is the idea people trip on most, so we slow all the way down.

In the figure the one if line (the orange diamond) sprays out into two arrows — the teal True arrow and the plum False arrow. This single picture explains the parent note's most important sentence: "one if is one line but two branch outcomes."

Why the topic needs this: the whole reason branch coverage is stricter than line coverage is that one line hides two outcomes. Miss this and the entire hierarchy stops making sense.

Not every fork has just two roads

The plain if is the simplest decision. Real code often forks into more than two roads at a single point, and each extra road is one more branch outcome to cover.

Why the topic needs this: the parent's branch-coverage formula counts every outcome of every decision. A 5-way switch contributes 5 to the "total outcomes" denominator, not 2 — miss this and you will under-count and think you are done when you are not.

The sneaky case: and / or inside one condition

There is a second way a single line can hide more than two roads, and it is the trap the parent note warns about most.

Why the topic needs this: the line reads as one if, and simple branch tooling may treat it as one decision with two outcomes. But finer tools count each operand (a, and separately b) as its own true/false decision — because the hidden second fork can hold an untested bug. This is exactly the gap the parent fills with condition coverage and MC/DC; see MC-DC Coverage for how each operand is forced to matter on its own.

4. The loop: a decision that can repeat

There is one more control shape, and it hides a decision inside it.

But loops do something dramatic to paths. A loop that runs 0 times, or 1 time, or 2 times, ... is a different route each time, because it walks the body a different number of times.

5. A complete route: the path

The difference between a branch outcome and a path is the difference between "did anyone ever turn left at fork 3?" (outcome) and "did anyone walk this exact whole route?" (path). That gap is where the path-count blow-up comes from — which we build next.

6. Counting paths: why they multiply (earning the symbol)

We now have the plain-word idea "different routes multiply". Only now do we attach a symbol to it.

Why 2, and why raised to a power? Each two-way fork offers exactly 2 roads (True/False). If you have $n$ such forks and the choice at each is independent of the others, then for every way of choosing the first fork you can pair it with every way of choosing the rest. Independent choices multiply:

$\text{paths}=\underset{n\text{ forks}}{\underbrace{2\times 2\times \cdots \times 2}}=2^n$

(If a decision is multi-way with $k$ roads instead of 2, that decision contributes a factor of $k$, not 2 — the counting rule is the same, you just multiply the number of roads at each point.)

The figure is a branching tree: 1 fork gives 2 leaves, 2 forks give 4 leaves, 3 forks give 8 leaves. Each leaf is a distinct path. Watch the leaf count double with every new fork.

7. The last symbols: the fraction bar and the percent sign

Now — and only now — we meet the two pieces of notation the parent's formulas use, because we finally have real quantities (units run, units total) to plug in.

Worked once so it is never mysterious: 2 lines run out of 3 total is $\frac{2}{3}=0.666\dots$, and $0.666\dots \times 100\%\approx 66.7\%$.

This is the single most important takeaway of the foundations: you already know all three formulas the moment you know what one "unit" means for each.

The prerequisite map

Every arrow means "you need the left idea before the right one makes sense." Notice how coverage at the bottom pulls together executable lines, branch outcomes, and paths — the three "units" — which is exactly why the parent gives three formulas that look almost identical.

Equipment checklist

Cover the right side and check you can answer each before reading the parent note.