Beautiful Testing

Testable Designs

Unlike other forms of specification, TDD directly influences the software’s design; if properly practiced, TDD ensures that the design is highly testable (Meszaros 2007). A testable system makes it easy for people and tools to:

• Set the starting state for the system/component and all dependent systems/components

• Control environmental factors, such as date and time

• Completely isolate the system/components from its dependents

• Trigger an action on the system/component

• Control responses from dependent systems/components

• Access all direct and indirect (side effect) outcomes

Designing a system for this type of flexibility, controllability, isolatability, accessibility, and repeatability involves new design strategies.

A typical three-tier architecture (Figure 14-5) is nicely layered, but often awkward to test. Control and validation typically are limited to the UI and database layers. It is impossible to substitute external components (operating system functions or third-party systems) because they are directly referenced throughout the code.

In contrast, a design that emerges from the TDD approach (Figure 14-5) is modular, with exposed interfaces and plug-in points to enable substitutions (e.g., mocks). When proper attention is paid to features supporting traceability (e.g., logging of inputs, intermediate steps, and results), the system itself facilitates automated testing, exploratory testing, and production support. Testing can be performed easily at any level. This is indeed ...