Get the book.

Lots of books about the practice of programming are written for raw beginners, for people who don’t know what they’re doing, who need their hand held gently, and often for people who don’t want to be studying this topic. They spend a lot of time coaxing and cajoling and telling little jokes to keep the kids from getting scared.

A second strand of recent books about programming, starting from Fowler’s Refactoring and Beck’s Test-Driven Development By Example, aren’t written for beginners but, like the children’s stories, they move in tiny steps and chiefly address topics that seem fairly simple. I read Refactoring from start to finish and, the whole time, I was convinced that the next chapter was going to get interesting. I finished it, shrugged, and a couple of weeks later I began to realize, “Hey! That was sort of interesting!” This predilection for great care in taking tiny steps is partly the result of the modernist preference for tiny-methods style, partly a matter of temperament, and (I suspect) partly the result of careers spent consulting for software managers who don’t really know what they’re doing but who hold the checkbook.

xUnit Test Patterns fits solidly in this tradition. It’s exhaustive and fairly exhausting, laying down the law for unit testing and showing in detail exactly how each step can be taken without fear of fouling everything up. Much of what’s covered here is probably already part of the working vocabulary of any programmer with enough experience to read the book, but because Meszaros gives names to stuff you already do, he makes it easier to talk about those things and to justify them.

I took away three things.

Everyone knows that unit tests really need to be fast. Meszaros puts a number on it: 100ms per test is not fast. Meszaros spends pages showing why 100ms is not fast. It’s overkill, presumably aimed at giving you lots of information to vanquish your pointy-haired boss, but it’s good to know.

Second, shared fixtures are a pain. I knew that. I’d developed a test style that returned fixtures to their proper state after I used them. Meszaros argues that it’s better just to make fresh fixtures if you can manage that, and this seems to me a big win.

Finally, there’s a fine paper on Humble Object by Mike Feathers that I’d missed. It’s a good reference to have.

So yes, it’s made a concrete difference in Tinderbox Six. I’m not sure this needed to be a book, and there’s another book about refactoring practice that’s trying to bust out of this one. But it’s certainly worth having and browsing this book, and you could do worse than to spend a few evenings working through it in detail.