Beautiful Testing

Readable Examples

It is essential that an Example can be clearly understood by a number of different audiences:

Nontechnical subject matter experts

These people verify that the Example is a correct and complete specification.

Technical team

These team members use Examples to drive their design and coding work. Toolsmiths read an Example to automate it; programmers read an Example to develop correct system code; operations support reads an Example to fix or enhance a specific part of the system.

A readable Example is all of the following (Andrea 2005):

• Declarative: expresses “what,” not “how”

• Succinct: includes only what is necessary

• Unambiguous: two people understand it the same way

• Autonomous: stands alone; does not depend on other Examples

• Sufficient: full coverage in minimal scenarios

• Locatable: organized and searchable

In Figure 14-2, the sample labeled “Test Script” is a traditional detailed functional test script, which is not what we are aiming for as a requirement specification: the tactical user interaction details obscure the business rule that needs to be expressed (in other words, the “how” eclipses the “what”).

Figure 14-2. Toward readable specifications

Creating a Domain-Specific Testing Language (DSTL) makes this same script more readable, provided the vocabulary of the specification is declarative and is expressed as business domain goals and real-world objects. In Figure 14-2