Review By: Harmon Avera Jr.
06/02/2008Traditional software development makes an assumption that the three basic steps for building software are to design, code, and test--in that order. In my thirty years of developing computer software, using this process often takes too long, doesn't deliver what the user wanted, doesn't deliver a correctly working product, and delivers systems that are brittle and hard to change. In Test Driven: Practical TDD & Acceptance TDD for Java Developers, Lasse Koskela inverts the paradigm into "test, code, design/refactor."

The book is divided into three major sections--a test-driven development (TDD) primer, applying TDD to specific technologies, and building products with acceptance TDD. Extra content, references, and code samples are available through a complimentary Web site. The book is aimed at experienced Java developers who are trying to build high-quality business and enterprise solutions as quickly as possible. The conversational writing style mixed with lots of well-annotated examples makes reading this book like sitting next to Koskela at a pair-programming terminal.

Koskela does an excellent job of explaining how TDD and acceptance TDD can help us make sure we "build the right thing right." He starts with the familiar JUnit tool to develop automated tests for class-level methods. Then he introduces available tools to test-drive development of higher-level systems, such as Web Components, Database access, unpredictable time-based or multi-threaded functions, and the Java Swing UI. I could immediately use some tools and TDD patterns from the section on test-driving changes and enhancements to legacy code in my current job. Also, using some ideas from the database access section allowed our team to reduce our integration test run times about fifteen percent.

The third part of Koskela's book describes a framework to define acceptance tests and a tool to translate the tests from the customer's language into a computer language that can be automated. He includes real-world techniques for implementing automated end-to-end acceptance tests and also discusses how the technology used in solution implementation can affect acceptance testing strategies.

I still love creating software and then seeing it actually work, but software development is now very much a team effort. The book's last chapter spoke most powerfully to me by addressing the people issues involved in getting TDD adopted by others. Koskela shares what's worked for him: finding opportunities to introduce TDD during development, recognizing different forms of resistance, and picking the right battles. This book has been both a reference and inspiration for me. Its style, content, and philosophy will be of use to me for a long time.