Top positive review
22 people found this helpful
All the important unit testing patterns and principles, but over-long
on 4 August 2007
Let me start by stating the obvious: this is a patterns book about the organisation of tests and the workings of the xUnit family of unit testing frameworks. It is _not_ a book about Test Driven Development, although there is material that is pertinent to that. Given that the use of JUnit and TDD is pretty intertwined in the minds of many Java developers, it's worth making this distinction, so you know what sort of book you're getting. Speaking of JUnit, most of the code examples uses Java, although there are some examples in C#, VB and Ruby.
Like Martin Fowler's Patterns of Enterprise Application Architecture, the book is split into two main sections, a narrative that weaves together a lot of the patterns and strategies, and then a catalogue of individual patterns. Between the two, there is a catalogue of 'test smells', similar to the 'code smells' discussed by Fowler in Refactoring, which I would suggest can be read profitably with the narrative section, rather than used as reference material.
There are a lot of patterns here on the mechanics of xUnit, such as 'Test Runner', 'Garbage-Collected Teardown' and 'Named Test Suite'. I was a bit confused about who this material is aimed at -- maybe someone looking at porting xUnit to a new programming language would find it useful, but a lot of it is fairly obvious to anyone who's used an xUnit in a non-trivial fashion (and certainly, if you haven't done so, this book is not a format that makes for a good introduction), or requires playing against xUnit's strengths (e.g. not putting setup and teardown code in their eponymous methods), although there is good reason for doing so in some of the examples provided, such as databases.
Beyond this, there is some good stuff on design-for-testability patterns (e.g. dependency injection versus dependency lookup), value patterns to replace magic constants, custom assertions and custom creation and other utility methods to make the intent of tests more clear. This material, along with the test smells chapter, is where the real value of the book lies. It encourages the application of the same software engineering principles you would apply to your applications (encapsulation, intent-revealing names, Don't Repeat Yourself) as you would to your testing code, something that's surprisingly easy to overlook, at least in my experience.
Also, the material on 'Test Doubles' (mocks, stubs, dummies and their ilk) is extremely useful. It touches on designing with mocks only superficially, but it does provide a helpful taxonomy of what different classes of doubles do. Now, if only everyone would standardise on this nomenclature, it would make life a lot easier. I suggest we brandish this enormous book threateningly at anyone who refuses to toe the line, and that should do the trick.
Because, boy, this book is big (about 900 pages). To be honest, it's too big. I rarely complain about getting too much book for my money, but the likes of the original GoF Design Patterns book, PoEAA and Patterns of Software Architecture Volume 1 manage to come in between 400-500ish pages, so there's no reason XTP couldn't. The advantage is that the patterns in the catalogue, which take up most of the space, stand alone, without requiring too much flicking backwards and forwards between patterns.
The disadvantage is that there is a lot of repetition, so unlike the three design patterns books I mentioned above, which I suspect most people read cover to cover (or maybe that was just me and I'm a complete freak), I would suggest only dipping into the catalogue as necessary. For instance, how much difference is there between the 'Testcase Class per Class', 'Testcase Class per Feature' and the 'Testcase Class per Fixture' patterns? Not a lot, as you might expect.
I definitely liked this book. I would have liked it even more if it came in at about half its size and I would have preferred more emphasis on test and assertion organisation than the mechanics of the xUnit framework, but maybe that would have been a different type of book to the one Gerard Meszaros intended. This is nonetheless a must buy for anyone who cares about unit testing.