4.2 Black and White Boxes

Now that we have studied the anatomy of single test methods, we will focus our attention on the test suite as a whole. But first, it appears useful to know a little about test nomenclature.

The literature [Binder99] distinguishes between black-box tests and white-box tests:

Black-box tests—also called specification-based or functional tests— look at the behavior of a system or unit from the outside. Only behavior that is available and visible from the outside is used in the testing code. Black-box tests can be created before the implementation is available with only the unit's specification at hand. Most acceptance tests in XP are pure black-box tests.
White-box tests are also called implementation-based or structural tests. They use knowledge about the current implementation of a function to determine complementary, critical test cases and execution paths. ^[4] A typical white-box test considers control flow or data flow of a program and derives the current input values for the test case from there.

The differentiation between black-box and white-box takes place on any level of focus. Seen from the outside, any testing of internal components is white-box testing. From a developer's point of view, however, the component itself can be tested with a black-box or a white-box mindset.

Adequate testing requires a combination of both approaches. All test cases we have developed so far were specification-based tests, because we concentrated solely on the desired behavior of an object. However, unit tests cannot be uniquely assigned to either of the two categories. Although we will continue trying to limit ourselves to the use of "external" properties of an object in our test cases, the choice of tests we make will be influenced by what we know about the implementation.

^[4]Knowledge about the implementation can also be used to identify superfluous black-box tests.