Chapter 78. Test-Driven Development
Dave Farley
Test-driven development (TDD) is widely misunderstood. Before TDD, the only thing that applied pressure for high quality in software was the knowledge, experience, and commitment of a programmer. After TDD, there was something else.
High quality in software is widely agreed to include the following properties in code:
-
Modularity
-
Loose coupling
-
Cohesion
-
Good separation of concerns
-
Information hiding
Testable code has those properties. TDD is development (design) driven by tests. In TDD, we write the test before writing code that makes the test pass. TDD is much more than “good unit testing.”
Writing the test first is important; it means that we always end up with “testable” code. It also means that coverage is never an issue. If we write the test first, we always have great coverage and don’t need to worry about it as a metric—and it is a poor metric.
TDD amplifies the talent of a software developer. It doesn’t make bad programmers great, but it makes any programmer better.
TDD is very simple—the process is Red, Green, Refactor:
-
We write a test and see it fail (Red).
-
We write the minimum code to make it pass and see it pass (Green).
-
We refactor the code, and the test, to make them as clean, expressive, elegant, and simple as we can (Refactor).
These steps represent three distinct phases in the design of our code. ...