Beautiful Testing

Examples Versus Tests

TDD has turned out to be an unfortunate name. When the phrase “test-driven development” is taken at face value, the specification activity is in danger of being confused with a testing activity. Functional requirement specifications begin to resemble detailed test scripts (see Figure 14-2 later), which are difficult to understand and maintain. Alternative terms have been proposed to focus attention on specification rather than testing, such as Examples,^[68] Behaviors,^[69] and Expectations (Hendrickson 2009). During an open space session at the 2008 Agile Alliance Functional Testing Tools program workshop,^[70] a group of practitioners developed the “TDD Triangle” (Figure 14-1) to clarify our terminology.

Figure 14-1. The “TDD Triangle”

A Requirement is a general statement describing how the system is expected to behave (aka feature or business rules). The Requirement is expressed in the vocabulary of the business domain. For example, in the domain of a video store point-of-sale system, one requirement is:

The Catalogue contains the list of all unique Movie Titles that the Video Store currently offers for purchase or rental.

Requirements are anchoring points for TDD. An Example (also known as acceptance test, story test, or functional test) elaborates a Requirement with concrete explanations of how the system will behave under specific conditions. Examples are expressed ...