---
name: white-box-testing
description: Use when asked to test software using knowledge of its internal code — statement/branch/path coverage, static and dynamic analysis — as distinct from black-box testing (see black-box-testing), which tests only inputs/outputs without code knowledge.
---

# White-Box Testing

White-box testing is done with complete knowledge of the internal
structure, code, and implementation of the application under test —
examining internal workings to verify every code path, condition, and
loop functions correctly. [[black-box-testing]] is the complementary
approach, testing from outside with no code knowledge.

## Coverage techniques

Test cases are designed by analyzing source code directly:

- **Statement coverage** — every line of code executes at least once.
- **Branch coverage** — every possible branch in a conditional executes
  (both the true and false side of every `if`).
- **Path coverage** — the most thorough level: every possible combination
  of paths through the code, which grows combinatorially with the number
  of branches and is rarely fully achievable on real-sized code.

## Automation

**Static analysis** tools examine code without executing it (style,
common bug patterns, some security issues); **dynamic analysis** tools
monitor behavior during actual execution (memory leaks, runtime security
vulnerabilities, performance bottlenecks). Both can track coverage
metrics and flag untested code segments automatically.

## Strengths and limits

Thorough code coverage and early detection of coding errors are the main
strengths, along with genuine optimization insight since the tester can
see exactly which code path a slow or buggy behavior traces through. The
tradeoffs: it requires real technical/programming expertise, can be
time-consuming at the path-coverage level, and — because it works from
the code, not the requirements — it may not catch **missing**
functionality (a requirement nobody implemented has no code to cover).

## Common pitfalls

- **Treating 100% statement coverage as "fully tested"** — a line can
  execute without its actual logic being meaningfully exercised (e.g. a
  branch condition that's always true in every test); branch and path
  coverage catch more of this gap.
- **Skipping black-box testing on the assumption code coverage is
  enough** — see [[black-box-testing]]; a well-covered
  implementation of the wrong requirement still fails users.
- **Chasing full path coverage on complex code** — the combinatorial
  explosion often makes this impractical; [[mutation-testing]] is a
  more tractable way to judge whether the existing test suite is actually
  effective, rather than just how much code it touches.

## Learn more

- [[black-box-testing]] for the complementary outside-only approach.
- [[mutation-testing]] for judging test-suite *effectiveness* beyond raw coverage.
- [[unit-testing]] for the level white-box technique is most commonly applied at.