Test-Driven Development: By Example — Kent Beck

What the book is about

Written by Kent Beck, Test-Driven Development: By Example does not explain TDD — it demonstrates it. Beck sits down and writes two applications from scratch, test first, and the reader watches every step: the failing test, the minimal code to make it pass, the refactoring to clean it up.

The TDD cycle is simple in description: Red → Green → Refactor. Write a failing test. Write just enough code to make it pass. Clean up. Repeat. The book’s contribution is showing what that cycle actually looks like over hundreds of small steps, across a realistic problem, with all the false starts and backtracking that real development involves. That honesty is what makes it valuable.

The Money example

The first and largest part of the book is the Money example: a multi-currency financial calculation system. Beck builds it entirely test-first, starting from the simplest possible test and expanding the design only when a new test demands it.

The example illustrates several things that are hard to appreciate without seeing them in practice:

• Design emerges from tests. Beck does not design the system upfront and then test it. The tests drive the design decisions. Classes, methods, and abstractions appear when they are needed and not before.
• Small steps compound. Each individual step feels almost too small. The cumulative effect is a well-structured, well-tested system that arrived there incrementally.
• Refactoring is part of the cycle. The Green phase produces working but often ugly code. The Refactor phase cleans it up without breaking anything. This discipline — never refactoring on a Red test — is what keeps the process safe.

Design patterns and refactoring

Throughout the Money example, Beck reaches for design patterns naturally — not as upfront architecture, but as responses to pressure the tests reveal. Value Object, Null Object, and Template Method appear not because a design document called for them, but because the tests made the need visible.

Refactoring is equally central. Beck applies the same techniques from Fowler’s catalogue — Extract Method, Inline, Replace Conditional with Polymorphism — as routine steps in the TDD cycle. The patterns and the refactorings are tools the tests justify, not decisions made in advance.

Mastering TDD

The final section steps back from the examples and addresses the practice directly. Beck covers the key questions every developer asks when starting with TDD:

• How large should a test step be? As small as necessary to make you feel confident.
• What do you test? Anything that could possibly break.
• When do you delete a test? When it no longer represents a unique condition.
• How do you test code that is hard to test? Redesign it so it becomes easy.

This section also addresses the relationship between TDD and design quality. Code that is hard to test is usually code that is hard to change. TDD does not just verify correctness — it provides constant pressure toward loosely coupled, well-structured design.

Personal note

This book is a great demonstration of how to develop software using TDD. The examples are complex enough to be realistic but written in a way that remains easy to follow. Watching Beck work through the Money example — making mistakes, reversing decisions, finding simpler solutions — is more instructive than any abstract explanation of what TDD is supposed to be.

Together with Refactoring by Martin Fowler and Clean Code by Robert C. Martin, it completes the practical side of this reading series: Beck shows you how to write tests that drive the design, Fowler shows you how to improve the design safely, and Martin shows you what the result should look and feel like.