Growing object-oriented software, guided by tests

About the book

Steve Freeman and Nat Pryce describe a way of building software in which tests come before and alongside the design. They treat test-driven development as a design discipline: writing a failing test forces you to name an object, define its responsibilities and decide how it talks to its collaborators. The code then grows in small, verified steps.

Much of the book concerns the craft of connecting tests to design decisions. It covers how to write tests that stay readable as a codebase expands, how to separate an object's concerns from the mechanics of testing it, and how to keep a test suite fast enough to run constantly. The authors work through outside-in development, starting from a feature and moving inward toward the objects that support it.

Freeman and Pryce write as practitioners describing a working method. The book is organized around building a real application, so the techniques appear in context. Expect discussion of mock objects, interfaces, and the tension between designing for testability and designing for clarity.

How to read it

Read with a code editor open. The arguments about test structure and object boundaries make more sense when you try them on a small piece of your own code. Pause to ask why a particular test is shaped the way it is.

The material assumes comfort with object-oriented programming and some prior exposure to unit testing. Readers new to either will find the early sections demanding. The examples build on one another, so skipping around can leave you without the context for a later technique.

Who it suits

Programmers who already write tests but suspect their tests are slowing design will find the most here. Developers working on long-lived codebases, where structure matters more than getting a prototype out the door, are the natural audience. Team leads looking for a shared vocabulary around testing and design will also get concrete material to discuss.

Reading considerations

The book reflects the testing tools and conventions of its time, so some example code and library references may feel dated against current frameworks. The central ideas about test-driven design outlast the specific tooling, but readers should expect to translate examples into their own stack. Treat the method as a set of arguments to test in practice.