Customer Reviews


60 Reviews
5 star:
 (29)
4 star:
 (16)
3 star:
 (6)
2 star:
 (6)
1 star:
 (3)
 
 
 
 
 
Average Customer Review
Share your thoughts with other customers
Create your own review
 
 

The most helpful favorable review
The most helpful critical review


42 of 43 people found the following review helpful
5.0 out of 5 stars Fail, Run, Run Clean
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...
Published on February 4, 2003 by Thomas Koenig

versus
47 of 54 people found the following review helpful
3.0 out of 5 stars A decent introduciton
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...
Published on March 12, 2004 by Jason


‹ Previous | 1 26 | Next ›
Most Helpful First | Newest First

42 of 43 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.
Help other customers find the most helpful reviews 
Was this review helpful to you? Yes No


45 of 48 people found the following review helpful
4.0 out of 5 stars Good introduction, but light on real-world development, November 28, 2003
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.
Help other customers find the most helpful reviews 
Was this review helpful to you? Yes No


47 of 54 people found the following review helpful
3.0 out of 5 stars A decent introduciton, March 12, 2004
By 
Jason (United States) - See all my reviews
(REAL NAME)   
This review is from: Test Driven Development: By Example (Paperback)
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.
Help other customers find the most helpful reviews 
Was this review helpful to you? Yes No


11 of 12 people found the following review helpful
4.0 out of 5 stars Intentionally slow-paced; this is a book on fundamentals, March 27, 2006
By 
Luke Meyers (Seattle, WA USA) - See all my reviews
(REAL NAME)   
This review is from: Test Driven Development: By Example (Paperback)
Many other reviewers have, with some justification, bemoaned the crunchingly slow pace of this book. Yes, the book moves through its examples slowly. Yes, sometimes Beck's mock humility comes off more than a little snide. It's not perfect on those counts, but please keep in mind that this is a book about a _process_, not a _result_.

The first example takes up almost half the book just to go through a pretty minimal implementation of a multi-currency representation for money. If this were a book about how to implement money representations, it would be a dismal failure. But of course, that's not the point at all -- the point is to use an example that's simple (so as not to be distracting), but just complex enough to produce adequate talking points to drive a discussion about test-driven development (TDD).

TDD is incredibly important, surprisingly late in arriving as a TLA unto itself, and Beck certainly gets points (cf. the review about "90% is just showing up") for producing a good straightforward introduction that's sorely needed. Nobody's going to come away from this book feeling filled to the brim with facts and sophisticated techniques. It's a short book (around 200 pages), and its pace is unhurried. What it does is focus on _fundamentals_.

TDD is all about buyin -- once you "get religion" and become "test-infected" (per Gamma), you've got a solid basis to grow from. It's about habits, and habits can be hard to teach. What's obvious to one person is mysterious to the next. Beck's approach of "sit here with me and listen to my thoughts on a simple, representative problem" is perfectly adequate. It concedes (repeatedly) that some of the steps are obvious, but the pages quickly and one never feels truly bogged down. He's really just teaching a handful of concepts throughout the whole book. You could write the concepts in a single paragraph; that's how much real, critical information is here. But it's _really good information_, and sometimes the key to grasping a fundamentally new (to you) viewpoint or idea is just hearing it rephrased for the 101st time, this time in words your brain is prepared to listen to.

So... it's a quick read, maybe a little pricey on that count. I'd say buy it anyway, and recoup the investment by loaning it to others on your team.

TDD is an incredibly beneficial infection; it's worth exposing yourself to a plainspoken explanation like this. You'll probably know within 50 pages whether you agree.
Help other customers find the most helpful reviews 
Was this review helpful to you? Yes No


23 of 28 people found the following review helpful
5.0 out of 5 stars From a Software Tester's Perspective, April 6, 2004
This review is from: Test Driven Development: By Example (Paperback)
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
Help other customers find the most helpful reviews 
Was this review helpful to you? Yes No


10 of 11 people found the following review helpful
5.0 out of 5 stars Allows you to judge TDD for yourself, April 17, 2003
Verified Purchase(What's this?)
This review is from: Test Driven Development: By Example (Paperback)
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.
Help other customers find the most helpful reviews 
Was this review helpful to you? Yes No


13 of 15 people found the following review helpful
2.0 out of 5 stars Unexpectedly underwhelmed, January 2, 2012
By 
Verified Purchase(What's this?)
This review is from: Test Driven Development: By Example (Paperback)
Based on the many glowing reviews of this book as well as the status of the author in regards to TDD, I purchased it expecting an actionable introduction to the style. So I'm surprised to find it's not only unusable for such purpose, but bad enough that I'm compelled to document the reasons here.

In particular, a lack of a complete, working summary of the code developed in the examples. Beck continually revises a single function (the test assertions) over the course of the first example (seventeen chapters), but nowhere presents a final, authoritative version. As well, Beck fails to mention the possibility that the tests could suffer from the same incorrect assumptions as the target code.

Beyond any specific deficiencies, Beck's particular style of iterative development leaves me questioning the value of the methodology toward building reliable and robust systems. Continually revising the test framework -- allowing for amendment or culling at any moment -- allows for tests that are manipulated until they pass whatever happens to compile at a given moment. This might be admissible in a team environment, but by itself, can't be more reliable than other approaches. And the singular focus of this book does nothing to explain the importance of using TDD within a larger development approach (one which probably includes revision control, pair-programming, and UX testing, say).

I truly hope that I'm wrong in my assessment, that I've missed a deeper lesson hidden within the text. I assume that I'm ignorant enough of the field to be unqualified to judge Beck's contributions. But when I came back here and read some of the longer, critical reviews, I found a lot of these same concerns already well noted. With no disrespect to the author, the book does little to help me learn TDD. It does not give a complete, clear path, despite being 'by example'. I would welcome any references to actionable expositions of TDD.
Help other customers find the most helpful reviews 
Was this review helpful to you? Yes No


18 of 22 people found the following review helpful
5.0 out of 5 stars helpful for cross-platform coding too, January 6, 2003
By 
C. K. Ray "agile sw developer" (Silicon Valley, CA United States) - See all my reviews
Verified Purchase(What's this?)
This review is from: Test Driven Development: By Example (Paperback)
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.
Help other customers find the most helpful reviews 
Was this review helpful to you? Yes No


55 of 72 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.
Help other customers find the most helpful reviews 
Was this review helpful to you? Yes No


7 of 8 people found the following review helpful
4.0 out of 5 stars Eye opening, January 22, 2005
By 
This review is from: Test Driven Development: By Example (Paperback)
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.
Help other customers find the most helpful reviews 
Was this review helpful to you? Yes No


‹ Previous | 1 26 | Next ›
Most Helpful First | Newest First

Details

Test Driven Development: By Example
Test Driven Development: By Example by Kent Beck (Paperback - November 18, 2002)
$49.99 $38.74
In Stock
Add to cart Add to wishlist
Search these reviews only
Send us feedback How can we make Amazon Customer Reviews better for you? Let us know here.