Shades of Testing
Testing is a monochromatic but varied discipline. Black-, white-, and gray-box testing frequent the vocabulary. Black-box testing aims to test the software based on the exposed functionality and external contract. On the other hand, white-box testing verifies the software with full knowledge of the internals. Somewhere in the middle of the spectrum, gray-box testing has been represented as black-box testing with educated guesswork about the internals or as white box-testing constrained by the portions of the internal knowledge that could be reasonably inferred or expected.
A desire to minimize the coupling between our tests and our code motivates this graduated taxonomy. If we only test what is externally promised by our objects, we will not make unwarranted assumptions in writing our tests. Many people feel that we should only write black-box tests as we move increasingly from the finer granularity of unit tests out to the coarse granularity of system tests. We will see later in the chapter that black-box testing is not sufficient to avoid coupling our tests to our implementations and that a greater degree of coupling arises from standard object-oriented design guidelines than we usually realize.
Black-box testing cannot sufficiently test our implementations, as shown by the buffered I/O example earlier. That leaves us to supplement it with white- or gray-box tests for thorough functional coverage, regardless of whether we use code coverage targets. However, tests with internal visibility often require the same kind of internal access that encapsulation aims to prevent.