Browse Books

Reviewer: Robert L. Glass

This book truly bugs me. There are so many levels at which I dislike it that it's hard for me to write an objective review. Perhaps this negativism of mine is more about me than it is about the book. Bug number 1: I've always been troubled by test-driven development, despite the fact that it's a well-respected technique liked by many, especially in the agile programming world. Some time ago, I even wrote a column about why I dislike it. If you care to, have a look at [1] where I explain why. Bug number 2: The author seems to delight in taking a details-first, generalities-second approach to every topic. For example, in discussing requirements definition sessions, he describes a scenario where the customer presents a tidy, complete, definitive algorithm that the program is to implement, and the book spends a great deal of time deriving from that a series of (incomplete, nondefinitive) examples as a way of describing what the customers want. There is enormous opportunity here for letting things fall through the cracks created by the examples, when there were no cracks in the original customer statement. The author even uses a term, "specification by example," for what I would call a misbegotten approach. In addition, the first 126 pages of the book focus on some detail-level case studies, followed by 77 or so pages on the "principles" underlying the method espoused. I've never seen a book before where I so much wanted to shout, "This is wrong!" Bug number 3: The book relies heavily on some tools and techniques that are insufficiently described. For example, a tool called "Cucumber" is used to create automated test cases, without any prior explanation as to why that tool is appropriate, or what it specifically does. Bug number 4 (minor): The book re-fights some obsolete religious wars, such as when it says, "Of course the tester uses emacs, not vi." Bug number 5 (minor): A lot of the book relies on readers knowing terms and tools they may not know. For example, it describes FitNesse, another tool it advocates, as "a Wiki system in which tests can be defined in a hierarchical way using Wiki pages." Perhaps you know what that means. I don't! I did kind of like some of the foreword material by other authors. For example, Kent Beck lauds the book for "not being printed on intellectual tissue paper that falls apart at first contact with the moisture of reality," but then I like even more the old saying that "reality is the murder of a beautiful theory by a gang of ugly facts." Kent also offers a nice and concise description of what the book wants to be about: "[It] takes you from 'here's a feature I'd like' to 'how are we going to test that__?__'" But surely, in a world well populated by test-driven development books, there is one that improves on this one in lots of ways. Online Computing Reviews Service