White-box testing

White-box testing designs tests by reading the code. The tester (often the developer) looks at the branches, conditions, loops and error handling and writes tests that exercise them deliberately. It is also called glass-box, clear-box or structural testing. Unit tests are the most common form, and code coverage is its usual measure.

Example

String grade(int score) {
    if (score < 0 || score > 100) {
        throw new IllegalArgumentException("score out of range");
    }
    if (score >= 50) {
        return "PASS";
    }
    return "FAIL";
}

Reading the code, you can see three outcomes (exception, PASS, FAIL), and the first if has two separate conditions that can each trigger the exception. Tests chosen from the structure:

Input	Path exercised
-1	score < 0 true, exception
101	score > 100 true, exception
50	in range, score >= 50 true, PASS
49	in range, score >= 50 false, FAIL

These give full branch and condition coverage. Testing exactly 50 and 49 also catches a >= accidentally written as >.

White-box vs black-box testing

White-box asks “does every path in this code behave correctly?” and needs the source. Black-box asks “does the system do what the requirements say?” and needs only the specification. White-box finds untested paths, dead code and logic errors in branches. Black-box finds missing features and behavior that disagrees with the requirements, which white-box cannot see because there is no code for a missing feature. Good suites use both.

Limits

• Tests can copy the code’s mistakes. If the developer misunderstood the requirement, tests written from the code will confirm the wrong behavior.
• Tight coupling. Tests that depend on private methods or internal structure break on every refactor even when behavior is unchanged. Test through public interfaces where possible.
• Coverage is not correctness. Executing every branch says nothing about whether the assertions are meaningful.