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