Contracts and Unit Tests

One might think that contracts are not needed when unit tests are written to the extent demanded by XP. However, we believe that contracts and unit tests supplement each other.

Unit tests set up a context, then perform a task and check the result. The context has to satisfy the task's preconditions for the test to work, but it never explicitly mentions those preconditions. A person browsing through some unit tests can derive the preconditions from the contexts that are set up. This is feasible for relatively simple test units. For subsystem interfaces, the unit test is complicated. In this case, implicit preconditions are hard to derive from the unit tests alone.

There is a partial solution to this problem: It is possible and frequent practice to write specialized unit tests that check whether interfaces fail gracefully when their implicit preconditions are not satisfied. However, it is hard to distinguish these unit tests from those testing for real user stories, and it is not much easier to derive the actual preconditions from them. Furthermore, multiple preconditions result in a combinatorial explosion of the number of unit tests. Therefore, unit tests cannot substitute explicitly formulated preconditions.

The relationship between unit tests and postconditions is somewhat less obvious. Both unit tests and postconditions give evidence of the expected result (or resulting context) of an action. Unit tests create an example situation and check an operation's result. Postconditions, though, describe the expected result in a more general manner, even though less detailed. As logical functions, they can describe an infinite set of possible results, and they can even exclude impossible ones.

Furthermore, contracts fit well into the "once and only once" principle of XP. They represent the universal (desired) semantics of a method, whereas unit tests represent only its semantics under a given assumption. Therefore, associating the contracts with their methods instead of their multitude of tests follows that principle. Besides, contracts for a set of classes that have a common superclass can be expressed in the superclass itself instead of repeating them in the unit tests of each subclass. This is also useful when the superclass is abstract and cannot be instantiated for testing.

As has been illustrated, unit tests and contracts address different, if somewhat overlapping, issues. Unit tests are a core practice of XP. Their presence is required throughout the life cycle of every XP project. Contracts are not crucial for XP to work. However, in a large system development effort that is partitioned into several loosely coupled subsystems, they can help ease communication difficulties that arise at their interfaces.