The TDD Cycle: Red-Green-Refactor

When doing TDD, you repeat a short cycle of the following:

1. Write a test (“red”).

2. Get the test to pass (“green”).

3. Optimize the design (“refactor”).

This cycle is often summarized as red-green-refactor, a phrase that stems from unit testing tools used for TDD. Red (fail) and pass (green) derive from SUnit (the first unit testing tool designed to support TDD^[8]) and similar GUI tools that use the colors to provide immediate feedback on test results. The text-based output of Google Mock uses red and green when executed in a terminal with color support.

During the refactoring step, you seek to ensure your codebase has the best possible design, which allows you to extend and maintain your system at reasonable cost. You refactor (a term popularized by Martin Fowler’s Refactoring: Improving the Design of Existing Code [FBBO99]) when you improve your code’s design without changing its behavior, something that having tests allows you to safely do. The Chapter 6, ​Incremental Design​ chapter covers refactoring.

Thinking and TDD

The goal of “burning the TDD cycle in your brain” is to make you comfortable with writing tests first to specify behavior and with cleaning up code each time through the cycle. Ingraining this habit will free your mind to instead think about the more challenging problem of growing a solution incrementally.

At each point in the TDD cycle, you must be able to answer many questions.

• Write a small test. What’s the smallest possible piece of behavior you can increment the system by (​What’s the Next Test?​, offers a few ideas)? Does the system already have that behavior? How can you concisely describe the behavior in the test’s name? Does the interface expressed in the test represent the best possible way for client code to use the behavior?

• Ensure the new test fails. If it doesn’t, why not? Does the behavior already exist? Did you forget to compile? Did you take too large a step in the prior test? Is its assertion valid?

• Write the code you think makes the test pass. Are you writing no more code than needed to meet the current set of behaviors specified by the tests? Are you recognizing where the code you just wrote will need to be cleaned up? Are you following your team’s standards?

• Ensure all the tests pass. If not, did you code things incorrectly, or is your specification incorrect?

• Clean up the code changes you just made. What do you need to do in order to get your code to follow team standards? Does your new code duplicate other code in the system that you should clean up, too? Does the code exhibit questionable smells? Are you following good design principles? What else do you know about design and clean code that you should apply here? Otherwise, is the design evolving in a good direction? Does your code change impact the design of other code areas that you should also change?

• Ensure the tests all still pass. Do you trust that you have adequate unit test coverage? Should you run a slower set of tests to have the confidence to move on? What’s the next test?

You’ll find ample resources in this book to help you answer these questions.

There’s plenty to think about every few moments throughout your development day. The cycle of TDD is simple, but the reality of building production-quality code rarely is. Doing TDD is not a mindless exercise.