All truths are easy to understand once they are discovered; the point is to discover them. -Galileo
Test-driven design (TDD) is a well-known developer’s practice in the software development industry, and it’s a practice favored by many as the best starting point for design after a developer has dissected a user story with the counsel of a functional user. So, although the label “test-driven” would lead you to believe that TDD is first a test method, in fact it is first a design method and only then a test method.
A Manager’s View of TDD
The general proposition is straightforward:
- Document a design requirement in the form of a test script, thereby accomplishing two tasks in one stroke.
- Then, run a test according to the script with the expectation of a failure—after all, nothing’s been designed and implemented. Of course, if the test doesn’t fail, then that means the product base already supports the requirement and nothing more’s to be done.
- If the test fails, then design and implement an object that will pass the test—in effect, design to pass. If the test passes, clean up the coding and documentation if needed, and update the product base with the new object.
This three-step cycle is commonly known as red-green-refactor after the idea that first the test fails (red), then the test passes (green), and finally the coding is upgraded to meet the project’s coding standards (refactor).
Some advantages to the TDD cycle are self-evident:
- Self-verification: The functional user story, the TDD test that proves the object faithfully implements the story, and the TDD design description or specification of the object are tightly coupled, and they are self-verifying—to change one requires validation with all.
- Lead to higher-level tests: The lead-in to unit testing and ultimately integration testing is a smooth arc from sponsor’s vision to user story via design, implementation, and integration.
- User in the loop: There is a virtuous circle, as illustrated in figure 1, which opens and closes on the user who stands in for all the beneficiaries of the project. The user validates the use case, validates the derived user stories, approves—for functional compliance, at least—the test script that is also the documentation of the design requirement, and then validates the integrated deliverables.
Figure 1: Virtuous Circle of TDD
Every testing doctrine like TDD is framed by a set of guidance principles set forth by the project manager and endorsed by the project team, as given by the examples in table 1.