Search in Book Reviews

Test-Driven Development (TTD) is split into three parts: Part I: The Money Example; Part II: The xUnit Example; and Part III: Patterns for Test-Driven Development.

I have some TTD experience and as I read Part I found it reassuring to see much of the process I use described in the book. It also taught me a few new things.

However, I had some of difficulty in following some of the code examples. This was mostly due to the code snippets being shown out of context and the lack of full code listings. This Part is split into a number of sections, and I think the book would be vastly improved if complete code examples were included at the end of each section.

Kent does state that the best way to appreciate the examples is to try them, but I feel this shouldn't be necessary and I use reading as a way of getting away from the screen. Despite the sparse code examples I managed to follow Part I, but only because I have used this sort of process before.

In Part II Kent develops a Python testing framework. During the introduction he states that he will "give a little commentary on Python". The commentary didn't materialise. Having done some Python in the past I just about followed it, but it took me a while to remember things such as data members in classes being declared the first time they are used. I also think that Python idioms like public data members and the need for 'self' to be passed to each member function should have been explained for those who haven't used a language like Python before.

Part III felt like a poorly thought out add on, trying to cover some of the material from the Gang of Four's Design Patterns book and Martin Fowlers Refactoring book in a much smaller space. The description of patterns doesn't seem to fit with the rest of the book. However, refactoring is a recurring theme throughout TDD and perhaps should have been given more space.

Throughout the book I found Kent's chatty style irritating, although perhaps it would appeal to those people who are as keen to enjoy the book as I was to extract and learn as much information as possible from it in the shortest period of time.

I would not recommend this book to someone I was trying to convince to use TDD, but I would (and have) recommend it to a colleague who has a basic understanding of the concept already.

This is the first programming book in a very long time that I haven't liked or enjoyed reading. However, this doesn't make it a bad book, just not a particularly good one.