Collective Wisdom from the Experts 161
in implementations to signify less than and greater than, respectively, program-
mers often mistakenly assume that these values represent the actual requirement
and consequently write tests that nail this assumption up in public.
A similar issue arises with tests that assert spacing, precise wording, and other
aspects of textual formatting and presentation that are incidental. Unless you
are writing, for example, an XML generator that offers configurable format-
ting, spacing should not be significant to the outcome. Likewise, hardwiring
placement of buttons and labels on UI controls reduces the option to change
and refine these incidentals in the future. Minor changes in implementation
and inconsequential changes in formatting suddenly become build breakers.
Overspecified tests are often a problem with whitebox approaches to unit test-
ing. Whitebox tests use the structure of the code to determine the test cases
needed. The typical failure mode of whitebox testing is that the tests end
up asserting that the code does what the code does. Simply restating what
is already obvious from the code adds no value and leads to a false sense of
progress and security.
To be effective, tests need to state contractual obligations rather than par-
rot implementations. They need to take a blackbox view of the units under
test, sketching out the interface contracts in executable form. Therefore, align
tested behavior with required behavior.