“Recommended, with reservations” is the rating my Cooks Illustrated magazine gives to products that can be used to get good food on the table, but that don’t quite meet the highest standards. I fear that’s the rating I have to give to Kent Beck’s new book on test driven design (TDD).

I’m willing to concede, however, that the problem may be as much with my high expectations for this book as with the book itself. TDD is an elaboration on chapter 18 in Beck’s previous book, “Extreme Programming Explained” (XPE). I think XPE is a great book; reading it changed how I work every day. But it covers a lot of ground, and the material on testing, while inspiring, is sparse. I was pretty excited when I heard Beck had a new book out, focused entirely on the unit testing methods of XP.

The motto at the top of the XPE chapter on testing serves the TDD book as well: “We will write tests before we code, minute by minute. We will preserve these tests forever and run them all together frequently.” I’ve been lucky enough to be working lately on a project with a unit test framework. I’ve had days where I lived up to the motto. But I can affirm that testing-first and testing-always is harder than it sounds, especially when working with a substantial pre-existing code base. I was eager to have some of my real world (read: maintenance and enhancement) questions answered. Unfortunately for me, the book’s approach to the material is still pretty introductory and evangelical.

Part 1 is a long, conversational example, using TDD to work up a Java multi-currency money-handling object. Beck’s intent is to give the reader the feel of some actual TDD work sessions, where the reader is his pair in a pair-programming environment. He also pushes hard on using the test driven approach as a way to build good design into code, without necessarily doing a lot of detailed design work up front. If you’ve read about test-first programming or unit-test frameworks, but haven’t had a chance to try them yet, this section could help you get enough of a feel to decide to take the plunge. If you are teaching new programmers, however, you could use this part as an assigned reading to convince them about how small they should be willing to work. I took a Java course at my local junior college last year, and the primary problem I saw novice programmers having was typing in way too much code, and then trying to get it to work. Beck’s relationship with his unit test framework is much like the one I’ve developed with my compiler. I’ll compile every line or two when I’m working on something hard, every few lines when I think the code is simple. But don’t be drinking a cup of coffee the first time you get to a description of Beck’s approach to “first make it run, then make it right:” you might choke. His “Fake It” technique is really no more than an extension of the stub-writing approach we all use, but it’s a radical extension.

Part 2 is another TDD example, this time using Python to construct a simple unit test framework. I’m sure this is the section that Beck refers to in the introduction, where he says that some reviewers got a lot more out of the examples when they fired up a development environment and coded along with the book. It not being my week to learn Python or build my own xUnit framework, I didn’t get much out of this section. If you do want a Python tutorial, or you do want to understand how the xUnit framework functions under the hood, coding along with this section may be exactly what you need.

Part 3, “Patterns for Test-Driven Development,” contains a wide-ranging set of observations on how to build and use unit tests and on refactoring. This is the section that will give the book a permanent place on my bookshelf, but even it is uneven in level and quality. The “Broken Test” tip for how to jumpstart your next programming section is a treat, and one I’ve already started using. The TDD-oriented list of refactorings, while no replacement for Martin Fowler’s excellent book on the subject, is certainly a handy top-ten list. I’ll be gnawing on the similarities, differences, and uses of value objects, null objects, and mock objects for a long time. The oracular pronouncement against singletons got me nowhere at all, however, and the “cheap desk, nice chair” tip would be better replaced with a bibliography pointing to, among other things, the many other good books that discuss productive coding environments in more detail.