In my previous blog post, I introduced AutoFixture's Freeze feature, but the example didn't fully demonstrate the power of the concept. In this blog post, we will turn up the heat on the frozen pizza a notch.

The following unit test exercises the BasketPresenter class, which is simply a wrapper around a Basket instance (we're doing a pizza online shop, if you were wondering). In true TDD style, I'll start with the unit test, but I'll post the BasketPresenter class later for reference.

public void AddWillPipeMapCorrectly()
    // Fixture setup
    var fixture = new Fixture();
    var basket = fixture.Freeze<Basket>();
    var mapMock = new Mock<IPizzaMap>();
    var pizza = fixture.CreateAnonymous<PizzaPresenter>();
    var sut = fixture.CreateAnonymous<BasketPresenter>();
    // Exercise system
    // Verify outcome
    mapMock.Verify(m => m.Pipe(pizza, basket.Add));
    // Teardown

The interesting thing in the above unit test is that we Freeze a Basket instance in the fixture. We do this because we know that the BasketPresenter somehow wraps a Basket instance, but we trust the Fixture class to figure it out for us. By telling the fixture instance to Freeze the Basket we know that it will reuse the same Basket instance throughout the entire test case. That includes the call to CreateAnonymous<BasketPresenter>.

This means that we can use the frozen basket instance in the Verify call because we know that the same instance will have been reused by the fixture, and thus wrapped by the SUT.

When you stop to think about this on a more theoretical level, it fortunately makes a lot of sense. AutoFixture's terminology is based upon the excellent book xUnit Test Patterns, and a Fixture instance pretty much corresponds to the concept of a Fixture. This means that freezing an instance simply means that a particular instance is constant throughout that particular fixture. Every time we ask for an instance of that class, we get back the same frozen instance.

In DI Container terminology, we just changed the Basket type's lifetime behavior from Transient to Singleton.

For reference, here's the BasketPresenter class we're testing:

public class BasketPresenter
    private readonly Basket basket;
    private readonly IPizzaMap map;
    public BasketPresenter(Basket basket, IPizzaMap map)
        if (basket == null)
            throw new ArgumentNullException("basket");
        if (map == null)
            throw new ArgumentNullException("map");
        this.basket = basket; = map;
    public void Add(PizzaPresenter presenter)
    {, this.basket.Add);

If you are wondering about why this is interesting at all, and why we don't just pass in a Basket through the BasketPresenter's constructor, it's because we are using AutoFixture as a SUT Factory. We want to be able to refactor BasketPresenter (and in this case particularly its constructor) without breaking a lot of existing tests. The level of indirection provided by AutoFixture gives us just that ability because we never directly invoke the constructor.

Coming up: more fun with the Freeze concept!


Interesting, interesting!
It's not clear from the example how using AutoFixture for DI keeps our tests testing object behavior better than setting up dependencies through the constructor or setters. I think it will suffer the same problems as we're examining private data. It has one benefit in that our public APIs remain pristine from adding in special-ctors/Setters for DI.

But hey, I'm going to play with this and see what happens. Thanks for the code sample!
2012-09-04 15:26 UTC
I have an upcoming article on how to decouple tests from constructor signatures, so stay tuned.
2012-09-04 19:05 UTC
One of the biggest complaints that architects have about TDD is allowing developers to redesign classes to allow for dependency injection. Even without strong change controls from top down, it would be convenient to be able to do DI without having to design for DI. (These cases come up with those doing Test Last rather than Test First/TDD.) Unfortunately this tool chain doesn't help this problem. Power Mock (Java: reprograms the class loader so this can be done without designing for DI. Perhaps a later release of this tool could as well. As of now, if I have to redesigning for DI[1], I don't need these other things as Moq already gives me this value.

Am I missing something?

[code]private readonly Basket basket;
private readonly IPizzaMap map;
public BasketPresenter(Basket basket, IPizzaMap map) // <-- redesign for DI
2012-09-18 15:49 UTC

Wish to comment?

You can add a comment to this post by sending me a pull request. Alternatively, you can discuss this post on Twitter or somewhere else with a permalink. Ping me with the link, and I may respond.


Friday, 26 March 2010 22:01:42 UTC


"Our team wholeheartedly endorses Mark. His expert service provides tremendous value."
Hire me!
Published: Friday, 26 March 2010 22:01:42 UTC