The Design of Independent Objects

It is appropriate to digress into a discussion of design here, because the activities of testing and design are closely related. Eric Evans’s book Domain-Driven Design discusses a form of what was previously called object-oriented analysis: finding the objects needed to solve a problem by interpreting a description of the problem. The process is straightforward. Take a description of the problem, and the things that do things are objects, the things they do are methods, and the things they tell or ask other things are messages. Evans proposes having a single “ubiquitous” language across the whole development team, so that the words used by the person who has the problem – the Goal Donor—http://wiki.c2.com/?GoalDonor are the same words as those used by the people building the solution. Borrowing an idea from Christopher Alexander, it is the ubiquitous language of the problem and solution domain in which one would expect to find a pattern language, as common aspects of problems become addressed in similar ways.

Behavior-Driven Development marries the technical process of Test-Driven Development with the design concept of the ubiquitous language by encouraging developers to collaborate with the rest of their team on defining statements of desired behavior in the ubiquitous language and using those to drive the design and implementation of the objects in the solution domain. In that way, the statement of what the Goal Donor needs is also the statement of sufficiency and correctness – that is, the description of the problem that needs solving is also the description of a working solution. This ends up looking tautological enough not to be surprising.