Customer Reviews

Test Driven Development: By Example

5 star:		(9)
4 star:		(5)
3 star:		(2)
2 star:		(1)
1 star:		(0)

 

 

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.

This is the most interesting book that I have read. During the first 20 pages, I dispise it. After 20 pages, I get it. After part I, I love it. At part III, I worship it!

The book start with example that involves teeny, weeny steps of test driven development that made me think this is really for people who don't know how to write test. And I consider myself to be a fully test-infected developer -- well, until I finally understand the idea that Kent is trying to convey here. It shows not only how to create a test case for a class, but also how to use test as the driving tool to assist refactoring for a better cleaner code. Becaus the way of development process is so much different from the normally way (well, depends on what you think is normally, isn't it), Kent carefully makes sure that the user doesn't get ahead of himself or herself. With little jokes here and little comments there, it really feels like being pair-programming with an XP mentor (it does, because I have been pair-programming with an XP mentor), who paitiently explains everything that is going on in his or her mind.

The second part of the book is also very unique. It goes through a process of using TDD to write a unit test framework. It shows, nicely, how to do TDD before the testing framework is in place, thus really tells what is the heart of TDD, and teaches a great lesson that TDD is not just writing test cases, but also a revolutionary development process.

The third part summrized patterns used in TDD, need I say more?

I like the way Kent Beck is doing is narrative inside the book. Of course it's less formal... but it's more comprehensive when you start. I love the way he infer some deeper knowledge of what you need to do. Dot not think of how a system should be designed but how you would like to execute it.

Excellent book. If you are starting TDD, it's must buy.

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

This book does a remarkable job of covering the philosophy behind good unit tests and frequent automated builds. The author is very forward thinking in the ideas presented.

If you want to get up to speed quickly then buy this book.

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.

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.

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.

This book has nothing in it that you don't know you should be doing. You know you should test your code. You know that you should make sure changes don't break things. I'll bet that you haven't actually taken the steps to make sure that you do this though.

Kent walks you through a good way to develop code: write the test code as you write the actual code. I've actually put this into practice and it's surprisingly easy to follow the recommendations. As you write a new function, write some code that calls it in a few different ways. When it comes time to give your code to someone else (check in to source control, deliver to customer, use on a bigger project), you have a fair sense that things will work.

Again, you already know that you should test things. This book presents one really great way to do that. It's worth taking a few hours and reading this one. Buy it so that you can re-read it once every year.

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.