Design

When software is developed using a test-driven approach, the Unit-Test may take the place of formal design. Each unit test can be seen as a design element specifying classes, methods, and observable behaviors. The following Java example will help illustrate this point.


Here is a test class that specifies a number of elements of the implementation. First, that there must be an interface called Adder, and an implementing class with a zero-argument constructor called AdderImpl. It goes on to assert that the Adder interface should have a method called add, with two integer parameters, which returns another integer. It also specifies the behaviors of this method for a small range of values.

In this case the unit test, having been written first, acts as a design document specifying the form and behaviors of a desired solution, but not the implementation details, which are left as an exercise for the programmer. Following the 'does the simplest thing that could possibly work' practice, the easiest solution that will make the test pass is shown below.

Unlike other diagram-based design methods, using a unit-test as a design has one significant advantage. The design document (the unit-test itself) can be used to verify that the implementation adheres to the design. UML suffers from the fact that although a diagram may name a class Customer, the developer can call the class Wibble and nothing in the system would note this discrepancy. With the unit-test design method, the tests will never pass if the developer does not implement the solution according to the design.

It is true that unit-testing lacks some of the accessibility of a diagram, but UML diagrams are now easily generated for most modern languages by free tools (usually available as extensions to IDEs). Free tools, like those based on the xUnit framework; outsource to another system the graphical rendering of a view for human consumption