White Box Testing

White-box testing (also called structural, glass-box, or clear-box testing) designs test cases based on the internal structure of the software—the source code, algorithms, control flow, and data structures. Unlike black-box testing that only considers inputs and outputs, white-box testing examines how the code works internally and creates tests to exercise specific code paths, branches, conditions, and loops. The tester has full visibility into the code and uses this knowledge to ensure thorough structural coverage.

Why White-Box Testing Is Needed

Black-box testing derived from requirements can miss defects in code that was written but never specified, error handling paths that requirements did not explicitly define, optimized code paths that behave differently from the general case, and dead code that should have been removed. White-box testing complements black-box testing by ensuring that all code actually written is exercised and verified, regardless of whether it traces to a specific requirement.

Coverage Criteria

White-box testing uses coverage metrics to measure testing thoroughness:

Statement Coverage

Every executable statement in the code must be executed at least once:

python example

def calculate_shipping(weight, expedited):
    cost = weight * 2.5                    # Statement 1
    if weight > 10:                        # Statement 2 (branch)
        cost += 15.0                       # Statement 3
    if expedited:                          # Statement 4 (branch)
        cost *= 2.0                        # Statement 5
    return cost                            # Statement 6

# Test 1: weight=15, expedited=True → executes ALL statements (100% coverage)
# But this single test misses the case where weight <= 10 AND not expedited!

Statement coverage is the weakest criterion—100% statement coverage does not guarantee all branches are tested.

Branch (Decision) Coverage

Every decision point must take both true and false paths:

python example

# For the function above, branch coverage requires:
# Test 1: weight=15, expedited=True   → both if-conditions TRUE
# Test 2: weight=5, expedited=False   → both if-conditions FALSE
# Now both branches of both decisions are covered

Condition Coverage

Each individual condition in a compound decision must be both true and false:

python example

if (age >= 18 and income > 50000):
    # Condition coverage requires:
    # age >= 18 TRUE and FALSE (test ages 25 and 15)
    # income > 50000 TRUE and FALSE (test incomes 70000 and 30000)

Path Coverage

Every possible execution path through the code is tested. This is the strongest criterion but often impractical—a function with N independent if-statements has 2^N paths.

Modified Condition/Decision Coverage (MC/DC)

Used in safety-critical software (aviation standard DO-178C). Each condition must independently affect the decision outcome. This provides strong coverage without the explosion of full path coverage.

White-Box Testing Techniques

Basis Path Testing

Uses cyclomatic complexity to determine the minimum number of independent paths through the code, then creates test cases for each:

python example

def process_order(order):
    if order.is_valid():                    # Decision 1
        if order.total > 100:              # Decision 2
            apply_discount(order)
        if order.customer.is_premium():     # Decision 3
            add_free_shipping(order)
        confirm_order(order)
    else:
        reject_order(order)

# Cyclomatic complexity = 3 decisions + 1 = 4 independent paths
# Path 1: invalid order → reject
# Path 2: valid, total <= 100, not premium → confirm (no discount, no free shipping)
# Path 3: valid, total > 100, not premium → discount + confirm
# Path 4: valid, total > 100, premium → discount + free shipping + confirm

Loop Testing

Specifically targets loop constructs with test cases for: zero iterations (loop body never executes), one iteration, two iterations (first repetition), typical number of iterations, maximum iterations, and maximum + 1 iterations (overflow check).

Data Flow Testing

Tracks variables from definition (assignment) through use (reading). Tests ensure every define-use pair is exercised—every variable is tested in contexts where it is defined and subsequently used.

Real-World Example: Tax Calculation White-Box Testing

java example

public double calculateTax(double income, String state, boolean selfEmployed) {
    double tax = 0;
    double federalRate;
    
    if (income <= 10000) {           // Branch 1
        federalRate = 0.10;
    } else if (income <= 40000) {    // Branch 2
        federalRate = 0.12;
    } else if (income <= 85000) {    // Branch 3
        federalRate = 0.22;
    } else {                         // Branch 4
        federalRate = 0.32;
    }
    
    tax = income * federalRate;
    
    if (selfEmployed) {              // Branch 5
        tax += income * 0.153;  // Self-employment tax
    }
    
    double stateRate = getStateRate(state);  // Branch 6 (inside getStateRate)
    tax += income * stateRate;
    
    return tax;
}

Branch coverage requires test cases that exercise: income in each bracket (≤10K, 10K-40K, 40K-85K, >85K), self-employed true and false, and various states. Minimum 8 test cases for full branch coverage versus the millions possible from equivalence partitioning of all income values.

Advantages of White-Box Testing

Identifies dead code (code that can never be reached), tests error handling and exception paths that requirements may not specify, verifies complex algorithms thoroughly by tracing execution paths, and provides objective coverage metrics that indicate testing thoroughness.

Limitations

Requires programming expertise (testers must read and understand code), cannot detect missing functionality (if a feature was never coded, there is no code to test), high test maintenance cost (code refactoring invalidates white-box tests even when behavior is unchanged), and may not reflect actual user scenarios (structurally covering all paths does not guarantee the right business scenarios are tested).

Complementing Black-Box Testing

The most effective testing strategy combines both approaches: black-box tests verify the system meets requirements from the user perspective, while white-box tests verify the code is structurally sound and thoroughly exercised. Together, they provide both requirements coverage and code coverage—a strong quality foundation.

Why White-Box Testing Is Needed

Coverage Criteria

White-box testing uses coverage metrics to measure testing thoroughness:

Statement Coverage

Every executable statement in the code must be executed at least once:

python example

def calculate_shipping(weight, expedited):
    cost = weight * 2.5                    # Statement 1
    if weight > 10:                        # Statement 2 (branch)
        cost += 15.0                       # Statement 3
    if expedited:                          # Statement 4 (branch)
        cost *= 2.0                        # Statement 5
    return cost                            # Statement 6

# Test 1: weight=15, expedited=True → executes ALL statements (100% coverage)
# But this single test misses the case where weight <= 10 AND not expedited!

Statement coverage is the weakest criterion—100% statement coverage does not guarantee all branches are tested.

Branch (Decision) Coverage

Every decision point must take both true and false paths:

python example

# For the function above, branch coverage requires:
# Test 1: weight=15, expedited=True   → both if-conditions TRUE
# Test 2: weight=5, expedited=False   → both if-conditions FALSE
# Now both branches of both decisions are covered

Condition Coverage

Each individual condition in a compound decision must be both true and false:

python example

if (age >= 18 and income > 50000):
    # Condition coverage requires:
    # age >= 18 TRUE and FALSE (test ages 25 and 15)
    # income > 50000 TRUE and FALSE (test incomes 70000 and 30000)

Path Coverage

Every possible execution path through the code is tested. This is the strongest criterion but often impractical—a function with N independent if-statements has 2^N paths.

Modified Condition/Decision Coverage (MC/DC)

Used in safety-critical software (aviation standard DO-178C). Each condition must independently affect the decision outcome. This provides strong coverage without the explosion of full path coverage.

White-Box Testing Techniques

Basis Path Testing

Uses cyclomatic complexity to determine the minimum number of independent paths through the code, then creates test cases for each:

python example

def process_order(order):
    if order.is_valid():                    # Decision 1
        if order.total > 100:              # Decision 2
            apply_discount(order)
        if order.customer.is_premium():     # Decision 3
            add_free_shipping(order)
        confirm_order(order)
    else:
        reject_order(order)

# Cyclomatic complexity = 3 decisions + 1 = 4 independent paths
# Path 1: invalid order → reject
# Path 2: valid, total <= 100, not premium → confirm (no discount, no free shipping)
# Path 3: valid, total > 100, not premium → discount + confirm
# Path 4: valid, total > 100, premium → discount + free shipping + confirm

Loop Testing

Data Flow Testing

Tracks variables from definition (assignment) through use (reading). Tests ensure every define-use pair is exercised—every variable is tested in contexts where it is defined and subsequently used.

Real-World Example: Tax Calculation White-Box Testing

java example

public double calculateTax(double income, String state, boolean selfEmployed) {
    double tax = 0;
    double federalRate;
    
    if (income <= 10000) {           // Branch 1
        federalRate = 0.10;
    } else if (income <= 40000) {    // Branch 2
        federalRate = 0.12;
    } else if (income <= 85000) {    // Branch 3
        federalRate = 0.22;
    } else {                         // Branch 4
        federalRate = 0.32;
    }
    
    tax = income * federalRate;
    
    if (selfEmployed) {              // Branch 5
        tax += income * 0.153;  // Self-employment tax
    }
    
    double stateRate = getStateRate(state);  // Branch 6 (inside getStateRate)
    tax += income * stateRate;
    
    return tax;
}

White Box Testing

Why White-Box Testing Is Needed

Coverage Criteria

Statement Coverage

Branch (Decision) Coverage

Condition Coverage

Path Coverage

Modified Condition/Decision Coverage (MC/DC)

White-Box Testing Techniques

Basis Path Testing

Loop Testing

Data Flow Testing

Real-World Example: Tax Calculation White-Box Testing

Advantages of White-Box Testing

Limitations

Complementing Black-Box Testing

Continue learning this concept

White Box Testing

Why White-Box Testing Is Needed

Coverage Criteria

Statement Coverage

Branch (Decision) Coverage

Condition Coverage

Path Coverage

Modified Condition/Decision Coverage (MC/DC)

White-Box Testing Techniques

Basis Path Testing

Loop Testing

Data Flow Testing

Real-World Example: Tax Calculation White-Box Testing

Advantages of White-Box Testing

Limitations

Complementing Black-Box Testing

Continue learning this concept