Black-box testing verifies a system through externally observable behavior while remaining independent of its internal implementation. Tests interact with the system as production code does and check outcomes meaningful to users. section 4.1 section 11.8
Apply the technique by following these rules:
- Assert the final result rather than private methods, internal state, algorithms, class structure, or source-code layout. section 4.1 section 11.8
- Prefer tests that survive refactoring and produce few false positives, even when implementation details change. section 4.1
- Use black-box testing when writing tests; use white-box analysis to examine test quality and regression protection. section 4.6
Testing message rendering
A brittle test inspects MessageRenderer's three sub-renderers and their order. A black-box test supplies a message and asserts the resulting HTML, such as "<h1>h</h1><b>b</b><i>f</i>". The latter remains valid if the rendering algorithm changes while the displayed result stays the same. section 4.1
Table 4.1. The pros and cons of white-box and black-box testing (view table figure)
| Protection against regressions |
Resistance to refactoring |
|
|---|---|---|
| White-box testing | Good | Bad |
| Black-box testing | Bad | Good |
Compare white-box and black-box testing by their trade-off: black-box tests provide weaker regression protection but stronger resistance to refactoring. section 4.5
