Quite simply, test-driven development is meant to eliminate fear in application development. While some fear is healthy (often viewed as a conscience that tells programmers to "be careful!"), the author believes that byproducts of fear include tentative, grumpy, and uncommunicative programmers who are unable to absorb constructive criticism. When programming teams buy into TDD, they immediately see positive results. They eliminate the fear involved in their jobs, and are better equipped to tackle the difficult challenges that face them. TDD eliminates tentative traits, it teaches programmers to communicate, and it encourages team members to seek out criticism However, even the author admits that grumpiness must be worked out individually! In short, the premise behind TDD is that code should be continually tested and refactored. Kent Beck teaches programmers by example, so they can painlessly and dramatically increase the quality of their work.

Average Customer Review: ( 42 customer reviews )
Write an online review and share your thoughts with other customers.

TDD fits development into a three micro-phase cycle: create a test that embodies your requirement, write code that passes the test, make the code run clean. Each phase has different goals, patterns and pitfalls. Like any good coach, Beck walks you through these in detail. He uses multiple examples: most notably a business model in Java and a unit testing framework in Phython. He follows up with a question and answer section that reviews common patterns in test driven development cycle.

The level of learning involved in doing TDD is profound. The best way to read the book is to do the book. Skills come from doing not reading. I did the examples (in another language) and it made all the difference in what I learned.

A footnote for managers: TDD is the opening wedge for a set of practices known as extreme programming (XP) or agile development. Test driven development is powerful enough to work on its own for the single delevoper. If you want to realize its full value, however, you need to embrace the full set of XP practices for the whole organization.

31 of 34 found the following review helpful:

Good introduction, but light on real-world developmentNov 28, 2003
By Lars Bergstrom "LarsBerg"
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.

38 of 44 found the following review helpful:

A decent introducitonMar 12, 2004
By Jason Menard
This Kent Beck title is an introduction to the world of Test-Driven Development (TDD). The book teaches the concepts of TDD by working through two complete sample projects. Along the way, Beck gives the reader valuable insight into the thought process and techniques behind successful test-driven development. When the reader has finished working through these sample projects, he should know enough about TDD to get started working on a TDD project.

The book is divided into three sections. The first two sections are each walkthroughs of the aforementioned sample projects using TDD. The third section is a collection of notes and useful tips to try to get the most out of TDD. If you've ever read anything from Beck, then you should be familiar with his style. If you haven't, Beck is an engaging enough writer, and the text flows smoothly and is fairly pleasant to read.

It would help to be familiar with some member of the xUnit family prior to reading this book. Beck uses Java and JUnit for the first section, but never really goes into discussing the JUnit API. Readers unfamiliar with xUnit may have no idea how to proceed with writing their own tests using one of these frameworks. True the API is simple enough that its functions may be ascertained simply by reading the code, but this is no reason not to provide explanation. The second sample project is an actual implementation of xUnit, so a bit more information may be gleaned here. Beck made the curious decision to use Python as the language of implementation for the second project, although he does provide explanation of the language's fundamentals. Finally, none of the sample projects are really complicated enough to do more than get us going on the path of TDD. There will still be many hurdles to climb when working on a real-world project.

If you are seeking a basic introduction to test-driven development, then you might enjoy this title. If you are a Java developer interested in exploring TDD more in-depth, there are better books out there.

54 of 67 found the following review helpful:

Poorly written...disappointingJan 05, 2003

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.

22 of 27 found the following review helpful:

From a Software Tester's PerspectiveApr 06, 2004
By Randy Rice "Software Testing Consultant & Trainer"
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

See all 42 customer reviews on Amazon.com