Tool Support
The numerous criticisms about the wastefulness of automating Examples argue they are bad tests in the sense that they rarely uncover new problems or errors of omission (Marick 2008). This goes back to the TDD misnomer, which confuses this practice with testing. TDD expects Examples to be automated to ensure that the requirements are trustworthy; automation is how we guarantee the specification is accurate over the entire life of the system. This is in sharp contrast to most other specifications, which become out of sync with the system as soon as development begins.
Automated Examples are subject to a high set of standards. Compared to production code, automated Examples must be:
More correct
Maintained as long or longer
More readable
Easier to write
More easily and safely maintained
More locatable
These statements are startling, and absolutely true. Automated Examples must be “more” than production code to eliminate the temptation to treat them as optional when pinched for time. Tools supporting automated Examples must also be “more” than development tools and testing tools to permit us to meet the high standards placed upon Examples.
The Agile Alliance Functional Testing Tools (AAFTT) workshops and discussion group give voice to the community of practitioners that need tools to support TDD. A beautiful TDD tool is one that offers the following core features to support the variety of roles engaged in the full process, shown in Table 14-2.
Table 14-2. Full TDD process
Author ... |
|---|
Become an O’Reilly member and get unlimited access to this title plus top books and audiobooks from O’Reilly and nearly 200 top publishers, thousands of courses curated by job role, 150+ live events each month,
and much more.
Read now
Unlock full access