Test Driven Development: By Example [Paperback]

Kent Beck (Author)

Book Description

ISBN-10: 0321146530 | ISBN-13: 978-0321146533 | Publication Date: November 18, 2002 | Edition: 1

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.

Editorial Reviews

From the Back Cover

Clean code that works--now. This is the seeming contradiction that lies behind much of the pain of programming. Test-driven development replies to this contradiction with a paradox--test the program before you write it.

A new idea? Not at all. Since the dawn of computing, programmers have been specifying the inputs and outputs before programming precisely. Test-driven development takes this age-old idea, mixes it with modern languages and programming environments, and cooks up a tasty stew guaranteed to satisfy your appetite for clean code that works--now.

Developers face complex programming challenges every day, yet they are not always readily prepared to determine the best solution. More often than not, such difficult projects generate a great deal of stress and bad code. To garner the strength and courage needed to surmount seemingly Herculean tasks, programmers should look to test-driven development (TDD), a proven set of techniques that encourage simple designs and test suites that inspire confidence.

By driving development with automated tests and then eliminating duplication, any developer can write reliable, bug-free code no matter what its level of complexity. Moreover, TDD encourages programmers to learn quickly, communicate more clearly, and seek out constructive feedback.

Readers will learn to:

Solve complicated tasks, beginning with the simple and proceeding to the more complex.

Write automated tests before coding.

Grow a design organically by refactoring to add design decisions one at a time.

Create tests for more complicated logic, including reflection and exceptions.

Use patterns to decide what tests to write.

Create tests using xUnit, the architecture at the heart of many programmer-oriented testing tools.

This book follows two TDD projects from start to finish, illustrating techniques programmers can use to easily and dramatically increase the quality of their work. The examples are followed by references to the featured TDD patterns and refactorings. With its emphasis on agile methods and fast development strategies, Test-Driven Development is sure to inspire readers to embrace these under-utilized but powerful techniques.

0321146530B10172002

About the Author

Kent Beck consistently challenges software engineering dogma, promoting ideas like patterns, test-driven development, and Extreme Programming. Currently affiliated with Three Rivers Institute and Agitar Software, he is the author of many Addison-Wesley titles.

See all Editorial Reviews

Product Details

• Paperback: 240 pages
• Publisher: Addison-Wesley Professional; 1 edition (November 18, 2002)
• Language: English
• ISBN-10: 0321146530
• ISBN-13: 978-0321146533
• Product Dimensions: 9.2 x 7.4 x 0.6 inches
• Shipping Weight: 1.1 pounds (View shipping rates and policies)
• Average Customer Review: 3.9 out of 5 stars  See all reviews (41 customer reviews)
• Amazon Best Sellers Rank: #34,880 in Books (See Top 100 in Books)
  • #11 in Books > Computers & Technology > Programming > Software Design, Testing & Engineering > Testing
  • #52 in Books > Education & Reference > Foreign Language Nonfiction > French
  • #92 in Books > Computers & Technology > Programming > Software Design, Testing & Engineering > Software Development

More About the Author

Discover books, learn about writers, read author blogs, and more.

Customer Reviews

Most Helpful Customer Reviews

29 of 30 people found the following review helpful:

5.0 out of 5 stars Fail, Run, Run Clean, February 4, 2003

By 

Thomas Koenig (Chevy Chase, MD United States) - See all my reviews

This review is from: Test Driven Development: By Example (Paperback)

The are a small number of writers who can teach programming skills effectively. Kent Beck is one of them. There are a small set of practices that you can adopt on your own that will have an clearly observable impact on the quality of your results and the quality of your work day. Test Driven Develoment (TDD) is one of them. If you are a software developer, you want to buy, read and study this book.

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 people found the following review helpful:

4.0 out of 5 stars Good introduction, but light on real-world development, November 28, 2003

By 

Lars Bergstrom "LarsBerg" (Chicago, IL) - See all my reviews
(VINE VOICE)    (REAL NAME)   

This review is from: Test Driven Development: By Example (Paperback)

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.

50 of 62 people found the following review helpful:

2.0 out of 5 stars Poorly written...disappointing, January 5, 2003

By A Customer

This review is from: Test Driven Development: By Example (Paperback)

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.