Test precisely and concretely

Test precisely and concretely

Kevlin Henney
IT is IMPORTANT to TEST for the desired, essential behavior of a unit of code, rather than for the incidental behavior of Its particular implementation. But this should is taken or mistaken as an excuse for vague tests. Tests need to be both accurate and precise.
Something of a tried, tested, and testing classic, sorting routines offer an illus-trative example. Implementing a sorting algorithm is not necessarily an every-day task for a programmer, but sorting is such a familiar ID EA that is most people believe they know-what-expect from it. This casual familiarity, however, can make it harder to see past certain assumptions.
When programmers was asked, "What's would you test for?", by far and away the most common response was something like, "the R Esult of sorting is a sorted sequence of elements. " While this is true, it's not the whole truth. When prompted-a more precise condition, many programmers add that the result-ing sequence should is the same length a S the original. Although correct, this is still not enough. For example, given the following sequence:
31415 9
The following sequence satisfies a postcondition of being sorted in non-descending order and have the same length as th E Original sequence:
33333 3
Although it satisfies the spec, it's also most certainly don't what were meant! This example are based on the error taken from real Production code (fortu-nately caught before it was released), where a s Imple slip of a keystroke or a momentary lapse of reason led to an elaborate mechanism for populating the whole result wit H The first element of the given array.
The full postcondition is, the result is sorted, and that it holds a permuta-tion of the original values. This appropriately constrains the required behavior.
?? 162 things every Programmer should Know
?
??????????????? That's the result length is the same as the input length comes out in the wash and doesn ' t need restating.
Even stating the postcondition in the "the" described is not enough to give you a good test. A good test should be readable. It should be comprehensible and simple enough so can see readily that it's correct (or not). Unless you already has code lying around for checking this a sequence is sorted and that one sequence contains a permutat Ion of values in another, it's quite likely that the test code would be a more complex than the code under test. As Tony Hoare observed:
There is, ways of constructing a software Design:one the-is-to-make it-so-simple, there is obviously no deficien Cies and the other was to make it so com-plicated this there is no obvious deficiencies.
Using Concrete examples eliminates this accidental complexity and opportu-nity for accident. For example, given the following sequence:
31415 9
The result of sorting is the following:
11345 9
No other answer would do. Accept no substitutes.
Concrete examples help-illustrate general behavior on an accessible and unambiguous. The result of adding an item to an empty collection are not simply that it's not empty:it are that the collection now have A single item, and then the single item held is the item added. The would qualify as not empty, and the would also be wrong. A single item of a different value would also is wrong. The result of adding a row to a table was not simply, the table is one row bigger; It's also that the row's key can used to recover the row added. And so on.
In specifying behavior, tests should not simply is accurate:they must also be precise.

Test precisely and concretely