TDD By Example Reviewed

I recently got a chance to read through Test Driven Development: By Example (The Addison-Wesley Signature Series) by Kent Beck. For those who don’t know, Kent, is the person behind eXtreme Programming and TDD, along with a laundry list of other items. Having not read many technical books cover to cover I wasn’t sure what to expect. I tend to use technical books as references not reading material. I was pleasantly suprised by how easy the book was to read, and how lightly it took itself. Mr. Beck is very passionate about developing in a way that is both productive and exciting. He discusses his frustration with existing approaches to development, and why he feels that TDD is a better approach. In many aspects I agree with Mr. Beck, but I also believe that there are two distinct types of Developers.

The first type are developers who love pretty pictures. My colleague Brian LeGros falls into this category. He enjoys diagramming until he has every nook and cranny defined, and ideally with the right tool he would just have to push go, and the bulk of the code would be generated. This camp tends to end up pushing ideas like MDSD that encourage drawing out everything and letting tools generate the details for you.

The second group loves to read and write code. These are the kind of people who typically get in trouble as systems get large, because they don’t document very well, and when another developer joins the team or takes over where they left off it is usually not pleasant. These people tend to fall into the Agile and XP camps. These are the people that will truly benefit from Mr. Beck’s book. TDD proposes a solution for this group to constantly be writing code, but keep the system documented and scalable.

I find myself each day falling more and more into the Agile/XP/TDD/BDD camps. I would very much prefer to look at code, than a picture. If I can rely solely on my unit tests, and compiler to tell me when I need to fix something that I refactored, I am all about it.

Overall the book cleared up some misconceptions I had about the TDD movement. For starters Mr. Beck is not nearly as strict as I imagined he would be…like a DHH for instance. He encourages many times throughout the book to take TDD and use it in your system slowly. I can remember numerous times he suggested “Doing what works best for you”. Usually he was talking in the context of what to test, and how large of a step to take in between tests.

Regardless of which camp you fall into I would strongly encourage you to check out this book. Even if you don’t adopt the TDD approach you can get many good refactoring ideas, as TDD is based heavily on refactoring. The only part of the book I would recommend skipping would be Part II. Unless of course you enjoy reading about a person implementing an xUnit framework in Python, and testing that very framework, with the framework, as he is writing it. Confused…yeah the section is just as confusing. However if you are interested in seeing how to bootstrap test your code it is a great section to read.