Browse Books

Reviewer: Anne Gunn

“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. Online Computing Reviews Service

Reviewer: Paul Strooper

This book provides a tutorial-style introduction to test-driven development, which is an approach to software development based around writing test cases first, making those test cases work, and then refactoring the code. Proponents of this methodology claim that this leads to ?clean code that works.? Although test-driven development is closely associated with extreme programming (this relationship is briefly discussed), the focus of this book is on the role of testing to drive the design and development process. Two practice-based examples are presented in the book, as well as a set of patterns that are used in those examples. The examples are in Java and Python, and the book requires readers to have some maturity with object-oriented design and programming. The first example, which is the core of the first 17 chapters, presents the test-driven development of a multi-currency arithmetic package. The example is used to introduce the ideas behind test-driven development and the supporting JUnit testing framework. Each chapter describes one small step in the typical test-driven development cycle, which consists of adding a test case that does not work (red), making the test case work quickly (green), and cleaning up the resulting code mainly by eliminating duplication (refactor). The author demonstrates how several iterations of the red-green-refactor cycle lead to a program that is well designed and works. Chapter 17 briefly reviews the status of the final program, and presents some statistics about it and the process that was followed. Example number two, covered in chapters 18 through 24, develops a framework for automated unit testing based on the xUnit architecture. It is developed in Python, and there is an explanation of some of Python?s features to assist in understanding the example. The example is more complicated, partially because the developed testing framework itself is used to test the developed code. Unlike the first example, this example is not completed. Chapter 24 concludes the example with a brief retrospective, but no data is presented on the final code or development process. The third part, containing chapters 25 through 32, presents patterns for test-driven development that were used in the book. It includes some general patterns for test-driven development in chapter 25, patterns for the red phase in chapter 26, patterns for test writing techniques in chapter 27, for the green phase in chapter 28, for using the xUnit framework in chapter 29, for design in chapter 30, and for the refactor phase in chapter 31. Most patterns are presented as questions, followed by brief answers and discussions. Illustrating examples are presented for some of the patterns. The book concludes in chapter 32 with some general questions and issues regarding the application of test-driven development in various situations. One of the most notable aspects of the book is the writing style, which is extremely ?chatty.? While some people might enjoy this style, I found it distracting; it makes the text more bulky than necessary. Regarding the content of the book, I believe that it is intended to sell readers on the idea of test-driven development, and to assist those that use test-driven development in becoming better at it. I believe the book has partially succeeded in the second role, but I do not think it will succeed in the first. For the first example, the author presents many small, straightforward steps, interspersed with one more complicated step (covered in chapter 12), which, as the author admits, requires a ?flash of insight.? I am not convinced that taking many such small steps will eventually lead to clean, working code, nor am I convinced that the ?flash of insight? will come at the right time in the design and development process. In other words, test-driven development may lead developers to flounder in long cycles of red-green-refactor without getting much closer to a clean, working design and code. (I am more worried about the ¿clean¿ than the ¿working¿ here.) For those people interested in improving their test-driven development skills, the two examples in the book present a wealth of practical tips and experience from one of the experts in the field. The steps used in the examples are small and explained well. The patterns presented in the third part are also useful, but a better link could have been made between the patterns and where they are used in the examples (some of this can be deduced from the index, but not systematically). Moreover, the patterns are mostly those used in the examples, and it would have been nice if reference(s) to ¿the comprehensive treatment found elsewhere¿ mentioned by the author had been included. Overall, while I believe the book does a good job as a tutorial on test-driven development, it is not a convincing advocate for this approach. Online Computing Reviews Service

Reviewer: Puneet Singh Lamba

The most important benefit of test-driven development (TDD) is that it forces developers to design object interfaces from the caller's perspective, which is the only perspective that should matter. A test is essentially a statement of intent. Therefore, in what Beck terms the initial red state, the test fails because only the intent exists. The implementation is missing. The developer then creates a stubbed implementation (Beck refers to this as faking), causing the test to pass. This is the green state. The third and final state, refactor, is the process of tuning functional code to make it more efficient and elegant. Of course, refactoring eventually breaks the system. Therefore, it is critical to have a suite of tests that can fail to indicate a broken system. A failed test returns the development process to the red state. Since the tests will catch any break in functionality, the developer is free to refactor without the usual associated apprehensiveness. The red/green/refactor cycle, of course, continues until the intended functionality is both complete and efficient. In the book's afterword, Martin Fowler notes that TDD (also known as test-first programming) results in a sort of "rapid unhurriedness" because it helps to break the problem down into individual tests, which then evolve through the red/green/refactor cycle. Fowler compares programming without TDD to juggling several balls (design, functionality, testing) all at once. TDD, he says, is the equivalent of focusing on one ball at a time: write the test (interface design), make the test pass (interface implementation or functionality), refactor (improve the design of the implementation code), and run the test (testing). Beck echoes the sentiment. Speaking of the reduction in stress he has experienced since adopting TDD, he writes, "No longer did I have to worry about everything at once." The tests and the code, therefore, evolve together, with the tests leading the code by a very small fraction [1]. The book also serves as a gentle introduction to Python, which has unit test-friendly language elements, such as the "pass" keyword to facilitate the stubbing of classes and methods. Part 2 of the book is the real gem. It leads the reader through the development of a JUnit framework using Python. The language, however, is not a barrier toward understanding the basic concepts of what a unit-testing framework must minimally offer. Beck recommends motivated developers to roll their own unit test framework in order to gain mastery over a tool they are likely to use several times a day. Beck's eccentricity permeates nearly every page, including when he asks the reader if she or he ever noticed that speculation and specification "come from the same [language] root." Beck recommends test isolation, and warns against test coupling (where two tests share objects and/or data creation). As he points out, test coupling can cause tests that run later in the sequence to report false results (both pass and fail). Clearly, the ultimate objective of TDD is to shorten the life cycle of as many bugs as possible by catching them early in the development cycle. To that end, Beck writes, "I've just been test driving development long enough that I can recover from most of my mistakes faster than you can recognize I've made them." Beck acknowledges that there is no scientific evidence that TDD reduces software defects, but claims overwhelming anecdotal evidence. A point that Beck alludes to in the last chapter is that TDD ensures that all of the code is by definition both testable and loosely coupled, to facilitate independent testing. A corollary of the above is that it is typically not feasible to retrofit tests for existing code because the code, as written, is not always testable. Since TDD requires that code only be written to make tests pass, and since tests are written only to represent use cases that the system must handle, it follows that the design of the system is not intended to be psychic about the functionality to follow. TDD's minimalism, with respect to design and infrastructure, will appear counterintuitive to those of us who grew up on a diet of big upfront design that is broad and flexible, in anticipation of possible system behaviors expected in the future. XP and TDD turn the age-old advice on its head, and suggest instead that the design should be the simplest, barest possible design needed to get the job done for the case at hand. Online Computing Reviews Service