xUnit Test Patterns

The first thing you notice with this book is the sheer size of it which is a little daunting. However you quickly realize that you don't actually need to read the entire thing cover to cover, the pattern based layout means that you can leave a lot of the content for use as a reference if you choose to.

Before getting to the patterns the book covers several other topics including test smells and principles, I thought these sections were as important as the patterns themselves so I thought I'd write a short section on each of them.

Test Smells

The smells are put into several categories:

1. Project - These could be around quality/cost/resources and are the sorts of things that a project manager might notice.
2. Behavior - You see these during compiling or running the tests, for example tests that are fragile.
3. Code - Problems with the quality of the test code, such as duplication.

Each section has multiple smells in it and each of the smells is discussed in a good level of detail.

Philosophy
This is covered, superbly, in chapter 4. Meszaros describes the fact that your testing philosophy will affect the way you test and that it is thus important to understand different approaches to testing. In particular he identifies some philosophical differences:

1. Test First or Last :- Whether to do true TDD, test last or something in between.
2. Test or Examples :- Do we view our unit tests primarily as specifications or tests.
3. Test-by-Test or Test All-at-Once :- Do we write a test then the code to fulfull it, work out all the tests for a class before writing the code or do something in between.
4. Outside-In or Inside-Out :-Highest level testing leading inwards to lower level testing or vice versa, can affect the way you test with dependencies.
5. State or Behavior Verification :-The same sort of thing as covered by Martin Fowler in his article Mocks Aren't Stubs. His view is that behavior (mock/interaction) testing can lead to tests that do a better job of isolating the system under test (SUT) but at the cost of more difficult refactoring.
6. Fixture Design Upfront or Test-by-Test :- How to handle your test fixtures, an important topic covered in superb detail in the book.

Meszaros then lists his personal philosophy:

1. Test first
2. Tests are examples
3. Write the tests one at a time, sometimes listing all the tests to help his thinking.
4. Outside in development helps clarify the tests to write at each level.
5. State verification is his preferred option, going for behavior (interaction or mocking based testing) verification where he needs to in order to increase coverage.
6. Performs fixture design on a test-by-test basis.

I personally found this chapter of the book excellent and it led nicely onto the section on principles.

Principles

Meszaros uses the term principles because they are not things that everyone will agree with and are too high level to be patterns, the list is discussed at this link but I've chosen to list the first three here:

1. Write the Tests First
2. Design For Testability :- Decouple ya hear.
3. Use the Front Door First :- Overuse of backdoor verification or behavior verification and mocking can result in overspecified software (fragile tests). The author recommends using behavior verification where appropriate, such as when doing layer crossing test.

Patterns

Subsequent sections cover test smells and patterns in more detail. I would say that some of the test patterns are less useful than others, but in general these sections are very comprehensive and will be useful whehter you choose to read them in detail or just use them as a reference.

How It Ties Together

What I love about this is that as you get to this chapter you begin to see how things tie together.

For example if your philosophy leads you to prefer state based verification (as the author does) then the principle of using the front door first makes sense to you.

This decision is then backed up by the later section on Interaction Styles and Testability Patterns which discusses why and when round-trip tests are preferrable to layer-crossing tests (not violating encapsulation being one advantage with the fact that you don't get overspecified software being another).

In turn you may then get smell of Behavior Sensitivity which can lead you to need to use the patterns Creation Method and Custom Assertions.

It is truly superb, you can really go from one section to another and see how it all ties together which is all important as if we don't really understand why we do what we do and what the alternatives are then we can't possibly choose the best path.

Even better the author forces you to see that there are multiple ways to test and each is valid, reminding you that you must be open minded about other peoples approaches.

Summary
This really is an excellent book, I'm not alone in thinking this either and Sam Gentile has posted about the book in the past and the reviews on Amazon are excellent.

I think I've learnt a lot from the book, its made me question some things and confirmed some of the ways we test. For example we currently use state based testing of our domain using the front door, which the author confirms is his preferred approach (its also the approach most DDD practitioners go for). However when someone joined our team recently she pointed out that our testing of our coordination layer could be improved if we focussed more on interation testing, especially as they are usually layer crossing tests.

If I have one issue with the book its that in some places it doesn't link togther too well. For example smells/principles/philosophies/patterns are linked and sometimes the relationships are not made clearly enough. A table linking a philosophy to principles then patterns and strategies might be worth trying coming up with...

Share This - Digg It • Save to del.icio.us • Stumble It! • Kick It • DZone