What are three main white box testing techniques?

The three main white box testing techniques are statement coverage, branch (decision) coverage, and path coverage. They form a hierarchy of increasing rigor: statement coverage checks that every line executes at least once, branch coverage checks that every true/false outcome of each decision runs, and path coverage checks that every independent route through the code is exercised.

White box testing (also called glass box or structural testing) inspects the internal logic of the code rather than only its external behavior. These three coverage-based techniques give you a measurable, objective way to know how thoroughly your test suite touches the source under test.

What Is White Box Testing?

White box testing is a method in which the tester has full visibility into the internal structure, design, and implementation of the software. Instead of treating the application as an opaque box, you design test cases based on the actual control flow, conditions, loops, and data paths in the code. This makes it ideal for unit and integration levels, where developers can trace exactly which lines and branches a test exercises. For a deeper primer, see the white box testing tutorial and how it compares in black box vs white box testing.

Consider this small function that we will reference across all three techniques:

public String grade(int score) {
    if (score >= 90) {
        return "A";
    } else if (score >= 60) {
        return "B";
    }
    return "F";
}

1. Statement Coverage

Statement coverage ensures that every executable statement in the code runs at least once. It is the most basic and easiest technique to measure. It quickly exposes dead code, unreachable statements, and lines your tests never touch. However, it is weak: a suite can hit 100% statement coverage yet still miss important logical outcomes.

For the grade function above, a single input like 95 executes the first return, and an input like 50 reaches the final return. The formula is straightforward:

Statement Coverage = (Executed Statements / Total Statements) * 100

2. Branch (Decision) Coverage

Branch coverage, also called decision coverage, requires that every branch of every decision point is taken at least once, meaning both the true and false outcomes of each if, else, switch, or loop condition. It subsumes statement coverage: exercising every branch necessarily runs every statement, but full statement coverage does not guarantee every branch. This is why branch coverage catches defects that statement coverage misses, especially an if with no explicit else.

For the grade function, you now need at least three inputs to force each decision both ways, for example 95 (first condition true), 70 (first false, second true), and 40 (both false).

Branch Coverage = (Executed Branches / Total Branches) * 100

3. Path Coverage

Path coverage is the most thorough of the three: it aims to execute every independent, feasible path from entry to exit through the code. It captures combinations of branches that decision coverage treats separately, making it the strongest technique for complex, branch-heavy logic. The catch is scale, because the number of paths grows exponentially with branches and loops.

The practical answer is basis path testing, which uses structural testing and cyclomatic complexity to derive the minimum set of independent paths. Cyclomatic complexity tells you exactly how many linearly independent paths exist:

Cyclomatic Complexity (V) = E - N + 2P
E = edges, N = nodes, P = connected components

A complexity value of 3 means you need three test cases to cover the basis set of independent paths, giving you strong coverage without chasing an exponential explosion of routes.

Other White Box Techniques Worth Knowing

Beyond the three core techniques, several complementary methods deepen structural testing:

• Condition coverage: ensures each boolean sub-condition evaluates to both true and false at least once, more granular than branch coverage.
• Loop coverage: exercises loops with zero, one, and many iterations to catch off-by-one and boundary defects.
• Data flow testing: tracks the define-use lifecycle of each variable to catch uninitialized or unused values.
• Mutation testing: injects small code changes to verify your tests actually detect them, measuring test strength rather than just coverage.

Common Mistakes and Troubleshooting

• Treating 100% statement coverage as "done": high statement coverage can still leave untested branches. Track branch coverage as your primary gate.
• Confusing branch coverage with condition coverage: branch coverage checks each decision outcome, while condition coverage checks each individual boolean operand.
• Chasing full path coverage: for anything non-trivial this is infeasible. Use cyclomatic complexity and basis path testing instead.
• Gaming coverage numbers: tests that execute code without meaningful assertions inflate coverage while catching nothing. Pair coverage with mutation testing.
• Ignoring loop boundaries: testing only the "typical" iteration count misses zero-iteration and maximum-iteration defects.

Validating White Box Coverage Across Real Browsers and Devices

White box techniques prove your logic is internally sound, but the same code must also behave correctly under real runtime conditions. Once your unit suite reaches strong branch and path coverage, the next step is validating those flows end to end across browsers, operating systems, and devices. TestMu AI lets you run automated and manual tests across 3000+ real browsers and devices, so a branch that passes in isolation is also confirmed on the environments your users actually run. You can combine this with automation testing and cross browser testing to pair structural coverage with real-world execution, and use code coverage to prioritize what to run in the cloud.

Conclusion

Statement, branch, and path coverage are the three main white box testing techniques, and each is stronger than the last. Start with statement coverage to eliminate untested and dead code, enforce branch coverage as your practical CI gate, and apply basis path testing guided by cyclomatic complexity where logic is complex. Layer in condition, loop, data flow, and mutation testing as your suite matures, then validate the results across real environments to ship with confidence.

Frequently Asked Questions

What are the three main white box testing techniques?

They are statement coverage, branch (decision) coverage, and path coverage. Statement coverage checks every line runs, branch coverage checks every true and false outcome runs, and path coverage checks every independent route through the code is exercised.

Is branch coverage stronger than statement coverage?

Yes. Branch coverage subsumes statement coverage because exercising every branch necessarily executes every statement, but the reverse is not true. You can hit 100% statement coverage while missing the false branch of an if that has no else.

Why is path coverage hard to achieve?

The number of paths grows exponentially with branches and loops, so full path coverage is impractical for large programs. Teams use basis path testing driven by cyclomatic complexity to cover a manageable set of independent paths instead.

What tools measure white box coverage?

Common coverage tools include JaCoCo and Cobertura for Java, Istanbul/nyc for JavaScript, Coverage.py for Python, and gcov for C/C++. Most report statement and branch coverage percentages that you can enforce as CI quality gates.

Is unit testing a white box technique?

Yes. Unit testing is usually white box because the tester writes cases with full knowledge of the internal code structure, deliberately targeting specific statements, branches, and conditions to raise coverage.

• What are the types of white box testing?
• What are the advantages of performing static white box testing?
• Is unit testing white box testing?
• What is code coverage?