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 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.

 

Guidance Principles
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.

Principle	Practices
Don't kill the messenger	Provide a safe and transparent environment. Celebrate inquisitiveness. Scorecard each result. Provide opportunity for timely reporting. Avoid accumulating a surprise. Look to the underlying cause with reasoned analysis.
Make every requirement testable; every test must relate to a requirement.	Decompose user stories until they are actionable. Involve users in the interpretation of stories into the actionable descriptions. Link specific requirements to test, and the other way around. Apply test-driven-design (TDD) techniques that translate user stories directly into test scripts. Provide a means for users to understand and approve test scripts at the functional level.
Anticipate some failure and make room for correction and retest.	Plan effort and duration, anticipating failures and correction tasks. Update a working plan from actual test results. Plan regression tests that do not cause the entire iteration test series to be re-executed. Allow for regression testing after refactoring.
Embrace learning.	Involve more than one person in the test scripting and execution. Build off of pair programming if that practice is in place. Follow proven "lessons learned" techniques: Ask "Why?" at least five times to push down through a hierarchy of related reasons. Apply logical reasoning: Abduction: Imagine that A is a possible explanation for B, although B may have many causes. Deduction: B is a likely consequence of A. Induction: A is a likely antecedent or condition of B Educate others on the team with the lessons learned. Apply what has been learned; modify best practices where necessary.
Avoid isolation.	Use the buddy system. Design/implement in pairs, test in pairs, or at least engage your others for critique and advice. Cross-check with others. Embrace socialization: Sit together; communicate daily, if not more often; and communicate with a sense of time urgency. Integrate objects into the design base often and maintain awareness of the evolution of the project.

Table 1: Test principles and practices [1]

The Fit of TDD
TDD was “invented” to serve a purpose. Martin Fowler, a respected thought leader in the agile space, opines: “TDD's origins were a desire to get strong automatic regression testing that supported evolutionary design.”[2]

TDD is more or less at the bottom of the testing hierarchy. Next up: unit tests. Unit tests, as distinct from TDD tests, are post-implementation design verification tests. In most respects, unit tests and TDD tests are very similar, but the purposes are very different: The latter drives design and the former is to verify implementation.

Unit tests feed into multiple object integration tests, system performance tests, functional tests, and perhaps others unique to the deliverables. All this fits into a pyramid we call the Test-driven Project Pyramid.

Project-level TDD
TDD in its customary description is a low-level design practice combined with a design test. But, project managers of necessity have a more strategic outlook. Consider the idea illustrated in figure 2.

Figure 2: Test-driven Project Pyramid

Notional concept: A notion in a conception which expresses the main ideas of the business sponsor but is bereft of many details like inclusions, exceptions, regulations, and implementation details of feasibility and support.

Every project begins with some notional idea—to wit, the problems to be solved or concepts to be implemented. For business reality, it’s also necessary to conceptualize what the metric evidence of success will be.

Notion synthesis is always an exercise in problem categorization, inter- and intra-problem relationships, and priorities. But, in design terms, notions are not actionable; thus, there follows a flow-down through the Test-driven Project Pyramid.

Business narrative: A narrative is a plain-language description of business operations. In other words, the narrative answers this question: What's the business operational context and working protocol for the notional concept? Within the pyramid, the narrative is the genesis of use cases.

Business rules provide operational governance for the narrative. Rules aren't processes, but processes enforce rules, whether the rules are implemented as workflow and function/feature controls or implemented administratively by the business.

Scripted cases: A scripted case is a test script form of the use case narratives derived from the business narrative. The scripted case primarily drives functional testing, but also drives performance testing if the test environment is a true operational setting.

Conditioned scenario: This is a scripted case with specific business conditions imposed for testing. An “instance” is a specific test execution of the conditioned scenario. An instance passes or fails.

Unit scripts: These are scripted tests that verify object function and performance to include integrated systems of objects.

TDD scripts: These are scripts that document the lowest level of user requirements.

Summary
TDD is a design practice combined with a test practice that gives rise to a close coupling of user stories, technical design requirement specification, and an object test script. For the most part, it is a three-step process: Write a test, run the test, and correct for any testing errors.

Although generally considered a low-level practice, project managers can drive project implementation from the view of test-driven project activity. The project is visualized as a TDD pyramid, with customary TDD at the bottom and script scenarios at the top.

References:

1. Goodpasture, John, Project Management the Agile Way: Making It Work in the Enterprise, 2010, J. Ross Publishing, Ft. Lauderdale, FL; Chapter 4, Table 4-1 (Reproduced with permission from J. Ross Publishing.)
2. Fowler, Martin, “Mocks Aren’t Stubs.”