Rating: 
Summary: 90% is Just Showing Up
Review: Everyone who's read about XP has wanted a book like this forever, so a decent performance was bound to be a happy occasion (a hot dog is a feast to a starving man). I would disagree with the last reviewer and say that the first part of the book is the good part, when the author works through his 'money' example. At the end of it, there's a great moment when Beck acknowledges the importance of metaphor, claiming that he'd done the same exercise a number of times, though this time, he had picked a better metaphor and it subsequently went a lot faster. I have to laugh at this. This is a case of obiter dicta (giving away the key to something in passing). But the funny thing is that Beck doesn't notice how important it is. He proceeds to just meander through the rest of the book. Then, the book just goes down the rathole as we feel like we're being treated to a prof who's run through his material and is just waiting for the bell. The section on patterns is abominable, ending with a thing on Singleton that says something like 'Don't use global variables, your programs will be happier,' which is a ridiculous capsulization of an issue that a lot of people have discussed many times before. A Singleton is globally available. It's not a variable. Mail servers are globally available too. Guess we shouldn't use them either. Let me also say that I am really kind of fed up with Kent Beck's Opi Taylor writing style. It's ok when the focus is on the KISS side of the equation and generally positive, but his snide little sideswipes throughout this book on everything from the open-closed principle to the idea of doing specifications (another searing, strong argument that boils down to the root of the word being the same as for the word speculation (!)) are really laughable. Makes me wanna say, yeah, who needs a spec if all they are doing is the 10 millionth payroll program or a currency converter. Don't look to Kent Beck for big answers, as a matter of fact, by his own half-conscious admission, he's as much in search of them as we are. So why 4 stars? Per the subject, the Woody Allen principle. Another hysterical part of this book is at the very end he shows a list of things someone else suggested, none of which are covered in the book, as if he had to tell us, at the end, that he knew just how much was missing.
Rating: 
Summary: Helpful, Simple and Brief
Review: I bought this book for two reasons: it teaches TDD and it's spine has the thickness of a deck of cards. I'll bet the XP adage "testEverythingThatCouldPossiblyBreak" is what prevents most programmers from taking up TDD. Who could blame them? If they truly tested all combinations and permutations they would take years to complete coding assignments and never stay employed. Without being explicit, the author breaks that adage and introduces a practical, simple means for adopting a habit of writing tests first. "Red/Green/Refactor" is the mantra that he shows through the money example, this is the path towards a "Clean Code that Works" objective. Honestly, I never got to parts II and III. Part I: "The Money Example" helped me clear the hurdles of tedium that you imagine in TDD; it alone is worth the price of the book.
Rating:
Summary: Helpful, Simple and Brief
Review: I bought this book for two reasons: it teaches TDD and it's spine has the thickness of a deck of cards. I'll bet the XP adage "testEverythingThatCouldPossiblyBreak" is what prevents most programmers from taking up TDD. Who could blame them? If they truly tested all combinations and permutations they would take years to complete coding assignments and never stay employed. Without being explicit, the author breaks that adage and introduces a practical, simple means for adopting a habit of writing tests first. "Red/Green/Refactor" is the mantra that he shows through the money example, this is the path towards a "Clean Code that Works" objective. Honestly, I never got to parts II and III. Part I: "The Money Example" helped me clear the hurdles of tedium that you imagine in TDD; it alone is worth the price of the book.
Rating: 
Summary: Poorly written...disappointing
Review: I bought this book with high expectations. I'm a true believer in testing early and often. Basically, I think the techniques have merit, but the presentation was lacking. I was disappointed with the writing -- all of the little asides that were attempts at humor fell flat and were distracting. The biggest disappointment was that a chapter on how to integrate these techniques into the processes of a project, especially a large project, was ommitted. At one point, the book states rather flippantly something to the effect that "You'll have to come up with your own argument to convince your boss to let you spend the time writing all these tests." I think that since he's the one promoting these techniques, he should be able to come up with those arguments. Personally, I think the argument is something like this:
- helps produce clean, modular code by forcing the designer to think about interfaces of the objects first. Coming up with good interfaces is half the battle.
- reduces defects tremendously because automated tests are available from the beginning and are used constantly.
- combines aspects of design and testing into the construction phase. So, the argument is that the "added" time spent writing tests saves time in the design and testing phases. I would have also liked to have seen a section on the dangers of stubbed out code. Since the technique causes you to stub out a lot of methods, as you go through the process and people are fallable, it warrants discussion. Sometimes they forget that some of the code is stubbed. I've seen situations where stubbed out code (ie, return true) provided the correct answer for a surprisingly long time. It wasn't until it got into system testing that some of the less frequently encountered data caused mysterious problems to come up in supposedly working code.
Rating:
Summary: From a Software Tester's Perspective
Review: I enjoyed reading this book, however I must advise that non-coders will probably have difficulty in staying with it. I don't mean that as a put-down of any kind. It's obvious that the intended audience is the developer who is trying to understand the concept of test-driven development. A tester, however, would learn in this book that test-driven development uses tests that are different in nature and rigor than those commonly thought of as "unit tests." I think Beck does a good job in explaining test-driven development in a way that is easy to understand. I still have some concerns about the nature of test-driven development, such as the emphasis on function over design. But I think Beck achieved a reasonable goal of presenting by example what test-driven development is all about. The goal of test-driven development is a reasonable way to achieve "clean code that works - now." As a tester, I think the awareness of test-driven development is a good thing. I also think that this technique must be combined with other methods, such as getting quality requirements, verification and validation, to achieve a final result that meets the users' needs. Readability - 4
Coverage of topics - 5
Depth of coverage - 5
Credibility - 5
Accuracy - 5
Relevance to software quality - 5
Overall - 5
Rating:
Summary: Eye opening
Review: I had been curious about test driven development (TDD) for quite a while before I read this book. After reading it and seeing the results in my code and in the overall design of my projects, I was amazed that a set of techniques could improve quality by so much.
TDD development involves a totaly different mind set than traditional coding and requires some personal dicipline until the habits kick in. Thankfully, the author doesn't spend a lot of time convincing the reader how great this "newest fad" is but focuses on using TDD realisticly in your current practices. The results are well worth it.
The text mostly assumes you have access to one of the xUnit testing frameworks but at the end there is a whole section on developing your own testing framework. I was really puzzled at first as to why the author would include this section. The obvious answer is that perhaps there isn't a testing framework in your current development environment. After further thought I realized that TDD is a mindset. For instance I have intermittently used assertions and although TDD focuses on external testing of functons, I could use assertions to test assumptions about parameters passed into functions. Although the assertions wouldn't be as robust as the unit tests they would add to the overall quality. I don' know if I would have made that connection before.
This is one of the more valuable books I have read.
Rating: 
Summary: Stops where it gets interesting
Review: I like the way Kent Beck writes his books. And it's sometimes thrilling to read his strange ideas. Having seen so many projects skip unit testing completely the idea of writing tests first strikes me as very good. Mr Beck presents his ideas very clearly and leads the reader through all subtleties and traps of a small example. That's exactly the point where things become interesting for me: How does the academic idea scale when being faced with Web apps, EJBs, XML/XSLT and so on? Hardly any hints about that which makes me wondering if the approach can be used for real projects.
Rating:
Summary: Good introduction, but light on real-world development
Review: If you've never done or are curious about TDD, this is a great book to carefully walk you through learning how and why to do it. After following its practices a bit, I've also found it an indispensible way to write new projects, modules, and code. However, the book doesn't address what happens when:
- The code base is old, and doesn't have any tests or isn't designed testable. It makes it hard to do anything other than introduce integration-level tests and tweak to success.
- You're writing UI code for a serious application. It's straightforward to solve for a dialog framework, but when you're integrating with a major windowing framework that embeds serious functionality (Avalon, in my case), there are a whole set of issues he doesn't talk about.
- Design is part of your deliverable. I don't disagree that you can get pretty reasonble designs out of TDD & refactor. But I *do* disagree that, in practice, you get designs intended to version well, that your company is willing to support for the next decade or more. I've seen the code produced, and it just doesn't happen. A good introduction, nonetheless. But watch out before you put on the preacher-hat after reading it and doing the exercises -- at least try to do it in part of one large, real-world product.
Rating:
Summary: helpful for cross-platform coding too
Review: It's about time that someone wrote this book. Some programmers have been doing test-driven-development since the earliest days of our profession, and the rest of us have been wondering why it is so hard to development software the "traditional" (non-TDD) way. Test-driven development (or as I prefer to call it, test-driven-design) helps you figure out the most useful interface to your class-under-test, without getting you into the psychological trap of not "really" wanting to test (and thus prove faulty) your "wonderful" code, because your code doesn't exist yet. The tests help you think about the implementation in small, mostly painless, steps. TDD also helps you write portable code. By getting portions of the logical parts of your application done first (the "model" of "model-view-controller"), you easily keep the logic code OUT of the GUI code. Typically, programming without test-driven-design makes it too easy to put all your logic into your GUI class. Almost all books on how to use MFC and other GUI class frameworks mix the logic code with view code -- you should read this book so you can be a better programmer.
Rating:
Summary: Allows you to judge TDD for yourself
Review: Let me say first off that I agree with much that Kent Beck has to say: 1. Testing should be done along with the coding. 2. Use regression tests to be confident of making changes. 3. In many ways testing can be used as documentation since it is much more definitive than specification documents. 4. Testing should be used to have the client sign off on a product. In reading the book I learned the specifics of how tests are designed in TDD. It seems reasonable and I am going to make a conscious effort at designing my tests in the way suggested. Where I disagree is in the use of the tests to drive software design. In the first part of the book, which I think is the most important part, a very good coding problem is analyzed - it is realistic, limited in scope and far from trivial. I followed along until I reached a point where things stopped making sense. I skipped ahead to see where things were headed and then things became clear. What is being advocated is a type of bottom up design approach. This may work for some. It may even be that the book faithfully reproduced Beck's reasoning process. It does not work for me. I first have to see the larger picture, what he refers to as the "metaphor." The whole thing would have been much clearer to me if at the beginning I was told that one approach to summing money in different currencies would be to use an array to store the information but that instead the implementation would create a list similar to how things are done in LISP. I urge the reader to judge for him/herself. Like I said this is a good example to go through. I even learned some things about more advanced uses of object oriented programming. As for software design I am going to stick with dataflow diagrams. They are still the best tool that I know of for putting together software, UML notwithstanding.
| 
