Miloslav Trmač

I generally prefer reference books to introductory tests, so when I got the opportunity to read Kent Beck’s Test Driven Development By Example, I was really surprised how easy to read—dare I say fun?—it was. It seems human brain is really set up to handle stories better than pure facts, and to enjoy them more—the book propels the reader through the text in no time, using the “what’s happening next?” feeling usually experienced only when reading fiction.

Taken from a very high level, most of the book is unsurprising: the basic idea of test-driven development can be explained in roughly five sentences, and the rest of the book follows naturally. The book does show quite a few techniques and tips on using the test-driven methodology, and it’s useful to read them all in one place, although most programmers would eventually discover most of them independently—but did I mention reading the book was fun?

The third part of the book, titled “Patterns for Test-Driven Development”, deviates from the “telling a story” format, and the difference is quite noticeable. Although the section is still interesting and useful, it tends a bit closer to the “patterns are so important the text must be repetitive and boring” style (of which The Gang of Four book is an instructive example) than I’d like. One particular section, which describes a very nice way to replace an internal data representation without breaking anything (this single section is a good enough reason for me to recommend the book!), contains two five-step recipes in a “How” subsection, and a detailed description in the “Why” subsection. The immediately following sections use the same “How”/”Why” pattern, in most cases unnecessarily—culminating with a completely ridiculous “How do you add a parameter to a method?” three-step program. Fortunately the “How”/”Why” pattern is gone in the next chapter.

I really missed a larger-scale example in the book; the examples provided very rarely contained a method longer than 10 lines, with roughly 3 lines being the average method size. Splitting a real-world program in so many small pieces of code seems to me rather impractical—it requires introducing too many helper objects to hold variables, and holding too many additional concepts (e.g. method names, object relationships) in one’s head at a time to be able to think about the overall algorithm spanning perhaps 100 or 200 lines. A larger-scale example that demonstrated how real-world code written using the test-driven development methodology could look like would be quite useful to evaluate the methodology in other terms than achieving outstanding test code coverage.

In any case, the book is interesting and fun to read – even if you “never have time to write tests”, don’t hesitate to read it if you get the opportunity.