4.6 White-Box Coverage

Core Idea

White-box testing derives tests from the internal structure of a component or system. The structure may be source code, control flow, data flow, architecture, or design. CTFL Foundation focuses on statement coverage and branch coverage.

White-box testing is often used at component and integration levels, but it can also support higher-level testing when structural information is available.

Statement Coverage

A statement is an executable instruction. Statement coverage measures the percentage of executable statements run by a test suite.

Formula:

statement coverage = executed statements / total executable statements * 100

Example pseudocode:

1 total = price * quantity
2 if total > 100 then
3   discount = 10
4 else
5   discount = 0
6 final = total - discount
7 return final

Assume each numbered executable line counts as a statement. If one test uses price 20 and quantity 3, total is 60. Lines 1, 2, 5, 6, and 7 execute. Lines 3 and 4 are not executable in the same way in many coverage tools, but for simple exam-style counting, focus on executable actions. If total executable statements are 6 and 5 execute, statement coverage is 83.3 percent.

A second test with price 60 and quantity 2 makes total 120 and executes the discount assignment. Together, the two tests can reach all executable statements.

Branch Coverage

A branch is an outcome of a decision. For a simple if statement, the branches are true and false. Branch coverage measures the percentage of decision outcomes executed.

Formula:

branch coverage = exercised branches / total branches * 100

Using the same pseudocode, the condition total > 100 has two branch outcomes:

If only the false test runs, branch coverage is 1 / 2 = 50 percent. If both tests run, branch coverage is 2 / 2 = 100 percent.

Why Branch Coverage Is Stronger

Branch coverage is stronger than statement coverage for decisions because it requires each decision outcome to be exercised. A suite can sometimes execute every statement without exercising every branch in more complex code structures, especially where decisions have no explicit else action.

Example:

if user_is_admin then
  show_admin_menu
show_home_page

A test with an admin user executes both statements. Statement coverage can be 100 percent, but the false branch of user_is_admin has not been tested. A non-admin test is needed for full branch coverage.

Full branch coverage generally implies full statement coverage for the same control flow model, but the reverse is not guaranteed.

Worked Coverage Example

Pseudocode:

1 if cart_total >= 50 then
2   shipping = 0
3 else
4   shipping = 7
5 if has_coupon then
6   discount = 5
7 else
8   discount = 0
9 return cart_total + shipping - discount

There are two decisions: cart_total >= 50 and has_coupon. Each has true and false outcomes, so there are 4 branches.

Test A: cart_total 80, has_coupon true. Branches covered: first true, second true. Branch coverage is 2 / 4 = 50 percent.

Test B: cart_total 20, has_coupon false. Combined with Test A, branches covered are first true, first false, second true, second false. Branch coverage is 4 / 4 = 100 percent.

Limits of White-Box Coverage

Coverage tools can show that code ran. They cannot prove the assertion was meaningful, the expected result was correct, or the requirement itself was complete.

A test may execute a branch and never check the output. That increases structural coverage but not confidence. Good tests need both execution and an oracle: a way to decide whether the observed result is correct.

White-box testing should complement black-box and experience-based testing. Structural coverage is a visibility tool, not a substitute for understanding user-visible behavior.