Test-Driven Development

Definition

Test-Driven Development (TDD) is the practice of writing an automated test that fails, then writing the minimum production code that makes it pass, then refactoring both the test and the production code while keeping all tests green. The cycle — red, green, refactor — repeats many times per hour. TDD is a design discipline as much as a testing discipline: the act of writing the test first forces clear thinking about the interface and behaviour of the code.

Why It Matters

TDD-developed code is, on average, better designed, better tested, and easier to change. Empirical studies vary in their estimates, but the consistent finding is significant defect reduction (20–60%) at a modest cost in development time (15–30%) and a substantial reduction in long-run maintenance cost.

The Cycle

• Red. Write a small, failing test that expresses the next required behaviour.
• Green. Write the smallest production change that makes the test pass.
• Refactor. Improve the design with all tests still passing.

Real-World IT Example

A trading-engine team adopted TDD strictly after a production incident traced to an under-tested edge case. Over twelve months, production incidents in the affected module dropped from 14 to 2, code coverage rose from 38% to 91%, and feature throughput — initially slower for the first two months — recovered and then exceeded the pre-TDD rate. The team attributed the speed gain not to coverage alone but to confidence: changes were made without fear, and reviews moved faster.

Real-World Construction Analogue

The construction equivalent is the discipline of "design for testability" in commissioning. On a $620M LRT depot, the systems integrator specified test points, sensors, and simulation interfaces during design — not after construction. Every subsystem could be tested in isolation before integration. The cost was 1.4% of design fee; the saving in commissioning rework was an estimated 8–11% of commissioning cost.

Common Mistakes

• Writing tests after code and calling it TDD. This loses the design benefit.
• Writing too-large a test. Tests should be small and focused.
• Skipping the refactor step. Without it, code quality decays.
• TDD as religion. Some code (exploratory spikes, UI prototypes) is poorly served by strict TDD.
• Testing implementation, not behaviour. Such tests break on every refactor.

Expert Tips

• Pair TDD with pair programming — particularly ping-pong style.
• Tests should describe behaviour in domain language; reviewers should understand them without reading the production code.
• Use TDD where the design is uncertain; it surfaces design issues fast.
• Resist mocking infrastructure; integration tests have a place.
• Measure test execution time; slow tests undermine the cycle.

Practical Lessons Learned

• The first month of TDD adoption is slow. Most teams that abandon it abandon during that month.
• TDD is most valuable on code that will be changed many times; least valuable on throwaway code.
• The discipline survives only with engineering leadership that protects it during deadline pressure.

Key Takeaways

• TDD writes the failing test first, then the production code, then refactors.
• It is a design discipline as much as a testing one.
• Expect a slow first month and a sustained-velocity gain thereafter.
• Pair with refactoring and pair programming for maximum benefit.
• The same "design for testability" thinking applies to commissioning in physical systems.

Related Encyclopedia Entries

• Continuous Integration
• Refactoring
• Pair Programming
• Definition of Done
• Technical Debt
• DevOps

Related Research Articles, Case Studies & Tools

• Project Controls Academy
• TDD Kata Library
• Learning Tracks: Software Engineering
• Books on Test-Driven Development
• Trading-engine TDD case study
• TDD defect-rate research