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.
- Format: Paperback
- Pages: 240 pages, Illustrations
- Publisher: Pearson Education (US)
- Publication Date: 08/11/2002
- Category: Software Engineering
- ISBN: 9780321146533
Showing 1 - 2 of 2 reviews.
Review by tuke
I must have read this back when it came out because I remember some of the jokes. This is a fascinating book about TDD, esp. if you read it now, given the maturation of the development model. On p. 199 there is a tantalizing section on "Application" TDD, where in a paragraph Beck anticipates BDD -- and how hard BDD can be if you don't properly rope in stakeholders as collaborators. I don't think we've figured that one out yet.<br/><br/>The book is a weird mix. First there's a section where Beck uses TDD to evolve an interface for handling money operations in different currencies. The section is a bit of a cheat, though, because first off Beck notes that he's done the "money" implementation 3 times in production, six times in print, and in live talks (p. 82): So the notion that he is somehow figuring out a problem or design with his TDD is pretty doubtful. He also notes in passing as he is working towards an implementation of a Sum class that it looks like a Composite pattern (p. 74) . . . that's right. He basically had the whole architecture in his head and is just kind of playing around. The section is also problematic because there's no complete source listing of the end product. Nowadays, it would be nice to have a full-blown commit list in github. On the other hand, it's all Java, and you have to wonder if it would take so long in, say, Ruby or Python.<br/><br/>Then there's a section on TDD'ing a Python xUnit. This section is quite forgettable. It's supposed to be "meta" and show you how you can TDD anything, but, really, it's pretty boring.<br/><br/>Then comes Part III: TDD Patterns. This bears close reading and has lots of little bits of advice, but you had better already be a "patterns" person. There are some interesting bits that show how far we've come from Java (for example: I can't imagine every doing a "self shunt" (p. 145) in Ruby.<br/><br/>We have really come a long way.<br/><br/>So: I recommend this for wisdom and for remembering the history. But if you're new to TDD I'm not sure this is the right place to start anymore.
Review by orcpac7
I found this book an approachable read for learning the how, what, when, why's of test-driven-development. Mr. Beck has both the knowledge to impart and the skills to communicate the concepts and practice of test drive development.