Condition and Path Coverage

Why it matters

Two tests give a decision full branch coverage however many conditions it holds. Suppose a developer forgets the brackets: account.active && amount <= account.dailyLimit || otpOk. Because && binds more tightly than ||, a blocked account with a confirmed one-time password (OTP) now gets its transfer approved. If the branch-coverage tests are all true and all false, both versions give the same results and the defect passes.

Wrong operators, missing brackets and conditions with no effect are typical defects in compound decisions, often in the rules that decide money and access. Condition-level criteria pick a few combinations that check each condition's effect on the decision, which is where these defects show, without testing every combination.

Conditions, decisions and condition coverage

As in the previous lesson, a decision is a point where the code chooses between outcomes, such as an if or a loop condition. The conditions are the Boolean expressions inside it; in the ISTQB glossary, an atomic condition is one that contains no logical operator. The function below has one decision with three atomic conditions: A is account.active, B is amount <= account.dailyLimit and C is otpOk.

Condition coverage measures which condition outcomes, true and false for each atomic condition, the tests exercised. It does not include branch coverage. Two tests, an active account over its limit without OTP (A true, B false, C false) and a blocked account within its limit with OTP (A false, B true, C true), give 100% condition coverage, yet both transfers are rejected and APPROVED never runs.

• Condition/decision coverage (also called decision condition coverage) closes the gap: it requires every condition outcome and every decision outcome.
• Short-circuit evaluation (short-circuiting in the ISTQB glossary): in JavaScript, Java and C#, && and || stop once the result is known (as do Python's and and or): when A is false, B and C are never evaluated. This lesson designs tests on the truth table, but at run time the blocked-account test above never evaluates B or C, so a tool that measures conditions would not count their true outcomes. Tools also differ: some count each operand as a branch, others only whole decisions or lines; check yours before reporting condition coverage.

 1  function reviewTransfer(account: Account, amount: number, otpOk: boolean) {
 2    if (account.active && (amount <= account.dailyLimit || otpOk)) {
 3      return 'APPROVED';
 4    }
 5    return 'REJECTED';
 6  }

Worked example: from condition coverage to MC/DC

Requirement: "A transfer within the daily limit is approved if the account is active. Above the limit it needs a confirmed OTP. Transfers from blocked accounts are always rejected." Three conditions give 2 × 2 × 2 = 8 combinations: list them as a truth table, as in the lesson on business rules, with the expected decision from the requirement.

Modified condition/decision coverage (MC/DC) requires each condition to be shown to change the decision on its own. The usual way is an independence pair: two tests that differ only in that condition and give different decisions. To find B's pair, keep A and C fixed, flip B and look for a change in the decision: with A true and C false, rows 2 and 4 give true and false. The aviation standard DO-178C requires MC/DC for its most critical software level, Level A.

• Condition coverage: rows 4 and 5, with the decision false in both. Condition/decision coverage: rows 1 and 8.
• MC/DC: rows 2, 3, 4 and 7. B is shown by rows 2 and 4, C by 3 and 4, A by 3 and 7. That is 4 tests for 3 conditions: MC/DC always needs at least one test more than the number of conditions.
• A could also use rows 2 and 6. Choose 3 and 7: row 7, a blocked account over its limit with OTP, exposes the missing-brackets defect. When a criterion leaves a choice, choose by risk.
• Multiple condition coverage: all 8 rows. It doubles with each condition; 10 conditions mean 1,024 combinations.

Decision: A && (B || C)
A = account.active    B = amount <= account.dailyLimit    C = otpOk

Row   A  B  C   Decision   MC/DC independence pairs
 1    T  T  T   T
 2    T  T  F   T          B: rows 2 and 4
 3    T  F  T   T          C: rows 3 and 4,  A: rows 3 and 7
 4    T  F  F   F          B: rows 2 and 4,  C: rows 3 and 4
 5    F  T  T   F
 6    F  T  F   F
 7    F  F  T   F          A: rows 3 and 7
 8    F  F  F   F

Condition coverage            rows 4, 5          decision never T
Condition/decision coverage   rows 1, 8
MC/DC                         rows 2, 3, 4, 7
Multiple condition coverage   all 8 rows

Try it: Decision Table Generator

Path coverage, and why loops make it explode

A path is one route through the code from entry to exit; path coverage asks whether the tests ran every route. Paths multiply: three if statements in a row have 8 paths, while two tests can cover all their branches.

Loops are far worse, because each number of iterations is a different path. In cartTotal, each item takes one of two routes, so a cart of n items has 2^n paths: 1,048,576 for a full cart of 20 and 2,097,151 in total. A loop without an upper limit has infinitely many. Some paths are also infeasible: their conditions contradict each other, so no input can run them.

• For loops, apply boundary values to the iteration count: zero, one, a typical number and the maximum (here 0, 1, 5 and 20 items), plus 21 where items are added, which the cart must refuse.
• Path thinking finds defects that need a sequence of routes, such as state left over from one iteration that breaks the next.

 1  function cartTotal(items: Item[]): number {   // a cart holds 0 to 20 items
 2    let total = 0;
 3    for (const item of items) {
 4      if (item.onSale) {
 5        total = total + item.salePrice;
 6      } else {
 7        total = total + item.price;
 8      }
 9    }
10    return total;
11  }

Items in cart     Paths
0                 1
1                 2
2                 4
3                 8
20                1,048,576
0 to 20           2,097,151 in total

Try it: Boundary Value Generator

Basis paths and cyclomatic complexity

Basis path testing, the core of the structured testing method in NIST SP 500-235, keeps paths manageable. Cyclomatic complexity, v(G), is the maximum number of linearly independent paths through a function's control flow graph: v(G) = edges − nodes + 2, where the edges are the graph's branches. When every decision is two-way, this equals the number of decisions plus one. A basis set is v(G) paths from which every other path can be combined.

cartTotal has two decisions, the loop and the if, so v(G) = 3, and three tests form a basis set: an empty cart, one regular item and one sale item. A basis set guarantees full branch coverage, not every combination: it is a systematic minimum, not complete path coverage.

• Counting only the if, reviewTransfer has v(G) = 2. NIST SP 500-235 also counts each short-circuit && and || as a decision, because each one can skip the rest of the expression, which gives 4; ESLint's complexity rule counts them too. Tools can differ, so compare figures from the same tool only.
• Treat a high v(G) as a signal: the function needs many tests and is hard to read, so it deserves closer review or refactoring.

Frequently asked questions

References

• 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.
• 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.