Review – xUnit Test Patterns

I consider one of the measures of quality of a book to be the number of personal assumptions challenged by its material.  To that point, Gerard Meszaros’ xUnit Test Patterns did not disappoint.

Perhaps the biggest assumption was a dogmatic view of what a unit test should look like without compromise.  There are benefits and liabilities to any choice made on test strategy, structure, organization, direction, and others.  Having options leads to making informed decisions instead of blindly following habits.  Looking back at my personal testing strategy over the past years, I fear I may have fallen into the latter.

Some of the major items I look to implement include:

  • Rigor in addressing test smells
  • Fitting the strategy to the situation, and not choosing a one-size-fits-all approach
  • Allowing myself to refactor tests (to fix such test smells)
  • Trying different organization styles

Part of the reason of the Fowler Signature Series’ success I believe comes in its organization.  While the length of xUnit Test Patterns seems daunting at first (833 pages!), it’s actually composed of two books.  This is what Martin Fowler refers to as a Duplex Book.

The first part consists of a set of narratives and tutorials, and makes up less than 200 pages.  The rest of the book focuses on patterns and reference material.  The first part can be read straight through, while the second can be referred to as needed.  While I carefully read the first section, it didn’t take longer than a Saturday afternoon to get through.  The rest of the book I’ll probably get to as I come up against specific situations and smells.

For those that are:

  • New to unit testing
  • Old pros to unit testing
  • Completely oblivious to unit testing

You’d do yourself (and your team and employer) a great service by giving xUnit Test Patterns a go.  If you wind up hating it, well, it’s big enough to make a fantastic door stop.

About Jimmy Bogard

I'm a technical architect with Headspring in Austin, TX. I focus on DDD, distributed systems, and any other acronym-centric design/architecture/methodology. I created AutoMapper and am a co-author of the ASP.NET MVC in Action books.
This entry was posted in TDD. Bookmark the permalink. Follow any comments here with the RSS feed for this post.
  • @Jimmy – after you read the book, what’s your thoughts on the various grammars related to BDD and specifications?

  • Yeah its a great book, though I must admit I found the books organization a little confused especially near the start (smells, goals, philosophy, principles).

    Anyway in my view its worth buying just for the section on Test Doubles, and the Website is also a great reference.

  • @Ray

    Which grammars are you talking about?

    Mostly it showed me that I shouldn’t be so strict in my naming or organization conventions. Pretty much showed me “here are all the things other people are doing in TDD”

  • @Jimmy – ah, I thought that it may have influenced your thinking on specifying BDD style specs. Nevermind. Different subject.

  • @Ray

    Well, that’s not entirely true. All these conversations about spec organization came into focus with the xUnit book, that there is more than one way to skin a cat. No reason to pick one way organizing for the life of the project. Different organization fits different scenarios, that’s all.