The new internal architecture of AutoFixture 2.0 enables some interesting features. One of these is that it becomes easy to extend AutoFixture to become an auto-mocking container.

Since I personally use Moq, the AutoFixture 2.0 .zip file includes a new assembly called Ploeh.AutoFixture.AutoMoq that includes an auto-mocking extension that uses Moq for Test Doubles.

Please note that AutoFixture in itself has no dependency on Moq. If you don’t want to use Moq, you can just ignore the Ploeh.AutoFixture.AutoMoq assembly.

Auto-mocking with AutoFixture does not have to use Moq. Although it only ships with Moq support, it is possible to write an auto-mocking extension for a different dynamic mock library.

To use it, you must first add a reference to Ploeh.AutoFixture.AutoMoq. You can now create your Fixture instance like this:

            var fixture
= newFixture()

    .Customize(newAutoMoqCustomization());

What this does is that it adds a fallback mechanism to the fixture. If a type falls through the normal engine without being handled, the auto-mocking extension will check whether it is a request for an interface or abstract class. If this is so, it will relay the request to a request for a Mock of the same type.

A different part of the extension handles requests for Mocks, which ensures that the Mock will be created and returned.

Splitting up auto-mocking into a relay and a creational strategy for Mock objects proper also means that we can directly request a Mock if we would like that. Even better, we can use the built-in Freeze support to freeze a Mock, and it will also automatically freeze the auto-mocked instance as well (because the relay will ask for a Mock that turns out to be frozen).

Returning to the original frozen pizza example, we can now rewrite it like this:

[Fact]

            public
            void AddWillPipeMapCorrectly()

{

    //
Fixture setup

    var fixture
= newFixture()

        .Customize(newAutoMoqCustomization());

    var basket
= fixture.Freeze<Basket>();

    var mapMock
= fixture.Freeze<Mock<IPizzaMap>>();

    var pizza
= fixture.CreateAnonymous<PizzaPresenter>();

    var sut
= fixture.CreateAnonymous<BasketPresenter>();

    //
Exercise system

    sut.Add(pizza);

    //
Verify outcome

    mapMock.Verify(m => m.Pipe(pizza, basket.Add));

    //
Teardown

}

Notice that we can simply freeze Mock<IPizzaMap> which also automatically freeze the IPizzaMap instance as well. When we later create the SUT by requesting an anonymous BasketPresenter, IPizzaMap is already frozen in the fixture, so the correct instance will be injected into the SUT.

This is similar to the behavior of the custom FreezeMoq extension method I previously described, but now this feature is baked in.

The last time I presented a sample of an AutoFixture-based unit test, I purposely glossed over the state-based verification that asserted that the resulting state of the basket variable was that the appropriate Pizza was added:

            Assert.IsTrue(basket.Pizze.Any(p
=>

    p.Name == pizza.Name), "Basket
has added pizza.");

The main issue with this assertion is that the implied equality expression is rather weak: we consider a PizzaPresenter instance to be equal to a Pizza instance if their Name properties match.

What if they have other properties (like Size) that don’t match? If this is the case, the test would be a false negative. A match would be found in the Pizze collection, but the instances would not truly represent the same pizza.

How do we resolve this conundrum without introducing equality pollution? AutoFixture offers one option in the form of the generic Likeness<TSource, TDestination> class. This class offers convention-based test-specific equality mapping from TSource to TDestination and overriding the Equals method.

One of the ways we can use it is by a convenience extension method. This unit test is a refactoring of the test from the previous post, but now using Likeness:

[TestMethod]

            public
            void AddWillAddToBasket_Likeness()

{

    //
Fixture setup

    var fixture
= newFixture();

    fixture.Register<IPizzaMap, PizzaMap>();

    var basket
= fixture.Freeze<Basket>();

    var pizza
= fixture.CreateAnonymous<PizzaPresenter>();

    var expectedPizza
= 

        pizza.AsSource().OfLikeness<Pizza>();

    var sut
= fixture.CreateAnonymous<BasketPresenter>();

    //
Exercise system

    sut.Add(pizza);

    //
Verify outcome

    Assert.IsTrue(basket.Pizze.Any(expectedPizza.Equals));

    //
Teardown

}

Notice how the Likeness instance is created with the AsSource() extension method. The pizza instance (of type PizzaPresenter) is the source of the Likeness, whereas the Pizza domain model type is the destination. The expectedPizza instance is of type Likeness<PizzaPresenter, Pizza>.

The Likeness class overrides Equals with a convention-based comparison: if two properties have the same name and type, they are equal if their values are equal. All public properties on the destination must have equal properties on the source.

This allows me to specify the Equals method as the predicate for the Any method in the assertion:

            Assert.IsTrue(basket.Pizze.Any(expectedPizza.Equals));

When the Any method evalues the Pizze collection, it executes the Equals method on Likeness, resulting in a convention-based comparison of all public properties and fields on the two instances.

It’s possible to customize the comparison to override the behavior for certain properties, but I will leave that to later posts. This post only scratches the surface of what Likeness can do.

To use Likeness, you must add a reference to the Ploeh.SemanticComparison assembly. You can create a new instance using the public constructor, but to use the AsSource extension method, you will need to add a using directive:

            using Ploeh.SemanticComparison.Fluent;

In the next couple of weeks I will be giving a couple of talks in Copenhagen.

At Community Day 2010 I will be giving two talks on respectively Dependency Injection and TDD.

In early June I will be giving a repeat of my previous CNUG TDD talk.

My book contains a section on the Ambient Context pattern that uses a TimeProvider as an example. It’s used like this:

            this.closedAt
= TimeProvider.Current.UtcNow;

Yesterday I was TDDing a state machine that consumes TimeProvider and needed to freeze and advance time at different places in the test. Always on the lookout for making unit tests more readable, I decided to have a little fun with literal extensions and TimeProvider. I ended up with this test:

            //
Fixture setup
          

            var fixture
= newWcfFixture();

            DateTime.Now.Freeze();

fixture.Register(1.Minutes());

            var sut
= fixture.CreateAnonymous<CircuitBreaker>();

sut.PutInOpenState();

2.Minutes().Pass();

            //
Exercise system
          

sut.Guard();

            //
Verify outcome
          

            Assert.IsInstanceOfType(sut.State,

    typeof(HalfOpenCircuitState));

            //
Teardown
          

There are several items of note. Imagine that we can freeze time!

            DateTime.Now.Freeze();

With the TimeProvider and an extension method, we can:

            internal
            static
            void Freeze(thisDateTime dt)

{

    var timeProviderStub
= newMock<TimeProvider>();

    timeProviderStub.SetupGet(tp => tp.UtcNow).Returns(dt);

    TimeProvider.Current
= timeProviderStub.Object;

}

This effectively sets up the TimeProvider to always return the same time.

Later in the test I state that 2 minutes pass:

2.Minutes().Pass();

I particularly like the grammatically correct English. This is accomplished with a combination of a literal extension and changing the state of TimeProvider.

First, the literal extension:

            internal
            static
            TimeSpan Minutes(thisint m)

{

    returnTimeSpan.FromMinutes(m);

}

Given the TimeSpan returned from the Minutes method, I can now invoke the Pass extension method:

            internal
            static
            void Pass(thisTimeSpan ts)

{

    var previousTime
= TimeProvider.Current.UtcNow;

    (previousTime + ts).Freeze();

}

Note that I just add the TimeSpan to the current time and invoke the Freeze extension method with the new value.

Last, but not least, I should point out that the PutInOpenState method isn’t some smelly test-specific method on the SUT, but rather yet another extension method.

About a month ago I decided to migrate from MSTest to xUnit.net, and while I am still in the process, I haven’t regretted it yet, and I don’t expect to. AutoFixture has already moved over, and I’m slowly migrating all the sample code for my book.

Recently I was asked why, which prompted me to write this post.

I’m not moving away from MSTest for one single reason. It’s rather like lots of small reasons.

When I originally started out with TDD, I used nUnit – it was more or less the only unit testing framework available for .NET at the time. When MSTest came, the change was natural, since I worked for Microsoft at the time. This is not the case anymore, but it still took me most of a year to finally abandon MSTest.

There was one thing that really made me cling to MSTest, and that was the IDE integration, but over time, I started to realize that this was the only reason, and even that was getting flaky.

When I started to think about all the things that left me dissatisfied, making the decision was easy:

• First of all, MSTest isn’t extensible, but xUnit.net is. In xUnit.net, I can extend the Fact or Theory attributes (and I intent to), while in MSTest, I will have to play with the cards I’ve been dealt. I think I could live with all the other issues if I could just have this one, but no.
• MSTest has no support for parameterized test. xUnit.net does (via the Theory attribute).
• MSTest has no Assert.Throws, although I requested this feature a long time ago. Now Visual Studio 2010 is out, but Assert.Throws is still nowhere in sight.
• MSTest has no x64 support. Tests always run as x86. Usually it’s no big deal, but sometimes it’s a really big deal.
• In MSTest, to write unit tests, you must create a special Unit Test Project, and those are only available for C# and VB.net. Good luck trying to write unit tests in a more exotic .NET language (like F# on Visual Studio 2008). xUnit.net doesn’t have this problem.
• MSTest uses Test Lists and .vsmdi files to maintain test lists. Why? I don’t care, I just want to execute my tests, and the .vsmdi files are in the way. This is particularly bad when you use TFS, but I’m also moving away from TFS, so that wouldn’t have continued to be that much of an issue. Still: try having more than one .sln file with unit tests in the same folder, and watch funny things happen because they need to share the same .vsmdi file.
• I suppose it’s because of the .vsmdi files, but sometimes I get a Test run error if I delete a test and run the tests immediately after. That’s a false positive, if anyone cares.
• MSTest gives special treatment to its own AssertionException, which gets nice formatting in the Test Results window. All other exceptions (like verification exceptions thrown by Moq or Rhino Mocks are rendered near-intelligible because MSTest thinks it’s very important to report the fully qualified name of the exception before its message. Most of the time, you have to open the Test Details window to see the exception message.
• Last, but not least, I often get cryptic exception messages like this one: Column 'id_column, runid_column' is constrained to be unique.  Value '8c84fa94-04c1-424b-9868-57a2d4851a1d, d7471c5e-522f-43d3-b2c5-8f5cab55af0e' is already present. This appears in a very annoying modal MessageBox, but clicking OK and retrying usually works, although sometimes it even takes two or three attempts before I can get past this error.

It not one big thing, it’s just a lot of small, but very annoying things. After three iterations (VS2005, VS2008 and now VS2010) these issue have still to be addressed, and I got tired of waiting.

So far, I can only say that I have none of these problems with xUnit.net and the IDE integration provided by TestDriven.NET. It’s just a much smoother experience with much less friction.

In my previousposts I demonstrated interaction-based unit tests that verify that a pizza is correctly being added to a shopping basket. An alternative is a state-based test where we examine the contents of the shopping basket after exercising the SUT. Here’s an initial attempt:

[TestMethod]

            public
            void AddWillAddToBasket()

{

    //
Fixture setup

    var fixture
= newFixture();

    fixture.Register<IPizzaMap>(

        fixture.CreateAnonymous<PizzaMap>);

    var basket
= fixture.Freeze<Basket>();

    var pizza
= fixture.CreateAnonymous<PizzaPresenter>();

    var sut
= fixture.CreateAnonymous<BasketPresenter>();

    //
Exercise system

    sut.Add(pizza);

    //
Verify outcome

    Assert.IsTrue(basket.Pizze.Any(p
=> 

        p.Name == pizza.Name), "Basket
has added pizza.");

    //
Teardown

}

In this case the assertion examines the Pizze collection (you did know that the plural of pizza is pizze, right?) of the frozen Basket to verify that it contains the added pizza.

The tricky part is that the Pizze property is a collection of Pizza instances, and not PizzaPresenter instances. The injected IPizzaMap instance is responsible for mapping from PizzaPresenter to Pizza, but since we are rewriting this as a state-based test, I thought it would also be interesting to write the test without using Moq. Instead, we can use the real implementation of IPizzaMap, but this means that we must instruct AutoFixture to map from the abstract IPizzaMap to the concrete PizzaMap.

We see that happening in this line of code:

fixture.Register<IPizzaMap>(

    fixture.CreateAnonymous<PizzaMap>);

Notice the method group syntax: we pass in a delegate to the CreateAnonymous method, which means that every time the fixture is asked to create an IPizzaMap instance, it invokes CreateAnonymous<PIzzaMap>() and uses the result.

This is, obviously, a general-purpose way in which we can map compatible types, so we can write an extension method like this one:

            public
            static
            void Register<TAbstract,
TConcrete>(

    thisFixture fixture) where TConcrete
: TAbstract

{

    fixture.Register<TAbstract>(() =>

        fixture.CreateAnonymous<TConcrete>());

}

(I’m slightly undecided on the name of this method. Map might be a better name, but I just like the equivalence to some common DI Containers and their Register methods.) Armed with this Register overload, we can now rewrite the previous Register statement like this:

fixture.Register<IPizzaMap, PizzaMap>();

It’s the same amount of code lines, but I find it slightly more succinct and communicative.

The real point of this blog post, however, is that you can map abstract types to concrete types, and that you can always write extension methods to encapsulate your own AutoFixture idioms.

My previous post about AutoFixture’s Freeze functionality included this little piece of code that I didn’t discuss:

            var mapMock
= newMock<IPizzaMap>();

fixture.Register(mapMock.Object);

In case you were wondering, this is Moq interacting with AutoFixture. Here we create a new Test Double and register it with the fixture. This is very similar to AutoFixture’s built-in Freeze functionality, with the difference that we register an IPizzaMap instance, which isn’t the same as the Mock<IPizzaMap> instance.

It would be nice if we could simply freeze a Test Double emitted by Moq, but unfortunately we can’t directly use the Freeze method, since Freeze<Mock<IPizzaMap>>() would freeze a Mock<IPizzaMap>, but not IPizzaMap itself. On the other hand, Freeze<IPizzaMap>() wouldn’t work because we haven’t told the fixture how to create IPizzaMap instances, but even if we had, we wouldn’t have a Mock<IPizzaMap> against which we could call Verify.

On the other hand, it’s trivial to write an extension method to Fixture:

            public
            static
            Mock<T>
FreezeMoq<T>(thisFixture fixture)

    where T
: class

{

    var td
= newMock<T>();

    fixture.Register(td.Object);

    return td;

}

I chose to call the method FreezeMoq to indicate its affinity with Moq.

We can now rewrite the unit test from the previous post like this:

[TestMethod]

            public
            void AddWillPipeMapCorrectly_FreezeMoq()

{

    //
Fixture setup

    var fixture
= newFixture();

    var basket
= fixture.Freeze<Basket>();

    var mapMock
= fixture.FreezeMoq<IPizzaMap>();

    var pizza
= fixture.CreateAnonymous<PizzaPresenter>();

    var sut
= fixture.CreateAnonymous<BasketPresenter>();

    //
Exercise system

    sut.Add(pizza);

    //
Verify outcome

    mapMock.Verify(m => m.Pipe(pizza, basket.Add));

    //
Teardown

}

You may think that saving only a single line of code may not be that big a deal, but if you also need to perform Setups on the Mock, or if you have several different Mocks to configure, you may appreciate the encapsulation. I know I sure do.

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.

[TestMethod]

            public
            void AddWillPipeMapCorrectly()

{

    //
Fixture setup

    var fixture
= newFixture();

    var basket
= fixture.Freeze<Basket>();

    var mapMock
= newMock<IPizzaMap>();

    fixture.Register(mapMock.Object);

    var pizza
= fixture.CreateAnonymous<PizzaPresenter>();

    var sut
= fixture.CreateAnonymous<BasketPresenter>();

    //
Exercise system

    sut.Add(pizza);

    //
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
          

{

    privatereadonlyBasket basket;

    privatereadonlyIPizzaMap map;

    public BasketPresenter(Basket basket, IPizzaMap map)

    {

        if (basket
== null)

        {

            thrownewArgumentNullException("basket");

        }

        if (map
== null)

        {

            thrownewArgumentNullException("map");

        }

        this.basket
= basket;

        this.map
= map;

    }

    publicvoid Add(PizzaPresenter presenter)

    {

        this.map.Pipe(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!

One of the important points of AutoFixture is to hide away all the boring details that you don’t care about when you are writing a unit test, but that the compiler seems to insist upon. One of these details is how you create a new instance of your SUT.

Every time you create an instance of your SUT using its constructor, you make it more difficult to refactor that constructor. This is particularly true when it comes to Constructor Injection because you often need to define a Test Double in each unit test, but even for primitive types, it’s more maintenance-friendly to use a SUT Factory.

AutoFixture is a SUT Factory, so we can use it to create instances of our SUTs. However, how do we correlate constructor parameters with variables in the test when we will not use the constructor directly?

This is where the Freeze method comes in handy, but let’s first examine how to do it with the core API methods CreateAnonymous and Register.

Imagine that we want to write a unit test for a Pizza class that takes a name in its constructor and exposes that name as a property. We can write this test like this:

[TestMethod]

            public
            void NameIsCorrect()

{

    //
Fixture setup

    var fixture
= newFixture();

    var expectedName
= fixture.CreateAnonymous("Name");

    fixture.Register(expectedName);

    var sut
= fixture.CreateAnonymous<Pizza>();

    //
Exercise system

    string result
= sut.Name;

    //
Verify outcome

    Assert.AreEqual(expectedName,
result, "Name");

    //
Teardown

}

The important lines are these two:

            var expectedName
= fixture.CreateAnonymous("Name");

fixture.Register(expectedName);

What’s going on here is that we create a new string, and then we subsequently Register this string so that every time the fixture instance is asked to create a string, it will return this particular string. This also means that when we ask AutoFixture to create an instance of Pizza, it will use that string as the constructor parameter.

It turned out that we used this coding idiom so much that we decided to encapsulate it in a convenience method. After some debate we arrived at the name Freeze, because we essentially freeze a single anonymous variable in the fixture, bypassing the default algorithm for creating new instances. Incidentally, this is one of very few methods in AutoFixture that breaks CQS, but although that bugs me a little, the Freeze concept has turned out to be so powerful that I live with it.

Here is the same test rewritten to use the Freeze method:

[TestMethod]

            public
            void NameIsCorrect_Freeze()

{

    //
Fixture setup

    var fixture
= newFixture();

    var expectedName
= fixture.Freeze("Name");

    var sut
= fixture.CreateAnonymous<Pizza>();

    //
Exercise system

    string result
= sut.Name;

    //
Verify outcome

    Assert.AreEqual(expectedName,
result, "Name");

    //
Teardown

}

In this example, we only save a single line of code, but apart from that, the test also becomes a little more communicative because it explicitly calls out that this particular string is frozen.

However, this is still a pretty lame example, but while I intend to follow up with a more complex example, I wanted to introduce the concept gently.

For completeness sake, here’s the Pizza class:

            public
            class
            Pizza
          

{

    privatereadonlystring name;

    public Pizza(string name)

    {

        if (name
== null)

        {

            thrownewArgumentNullException("name");

        }

        this.name
= name;

    }

    publicstring Name

    {

        get { returnthis.name;
}

    }

}

As you can see, the test simply verifies that the constructor parameter is echoed by the Name property, and the Freeze method makes this more explicit while we still enjoy the indirection of not invoking the constructor directly.

In a previous post I described how AutoFixture's Do method can let you invoke commands on your SUT with Dummy values for the parameters you don't care about.

The Get method is the equivalent method you can use when the member you are invoking returns a value. In other words: if you want to call a method on your SUT to get a value, but you don't want the hassle of coming up with values you don't care about, you can let the Get method supply those values for you.

In today's example I will demonstrate a unit test that verifies the behavior of a custom ASP.NET MVC ModelBinder. If you don't know anything about ASP.NET MVC it doesn't really matter. The point is that a ModelBinder must implement the IModelBinder interface that defines a single method:

In many cases we don't care about one or the other of these parameters, but we still need to supply them when unit testing.

The example is a bit more complex than some of my other sample code, but once in a while I like to provide you with slightly more realistic AutoFixture examples. Still, it's only 10 lines of code, but it looks like a lot more because I have wrapped several of the lines so that the code is still readable on small screens.

The first part simply creates the Fixture object and customizes it to disable AutoProperties for all ControllerContext instances (otherwise we would have to set up a lot of Test Doubles for such properties as HttpContext, RequestContext etc.).

The next part of the test sets up a ModelBindingContext instance that will be used to exercise the SUT. In this test case, the bindingContext parameter of the BindModel method is important, so I explicitly set that up. On the other hand, I don't care about the controllerContext parameter in this test case, so I ask the Get method to take care of that for me:

The Get method creates a Dummy value for the ControllerContext, whereas I can still use the outer variable bindingContext to call the BindModel method. The return value of the BindModel method is returned to the result variable by the Get method.

Like the Do methods, the Get methods are generic methods. The one invoked in this example has this signature:

There are also overloads that works with the versions of the Func delegate that takes two, three and four parameters.

As the Do methods, the Get methods are convenience methods that let you concentrate on writing the test code you care about while it takes care of all the rest. You could have written a slightly more complex version that didn't use Get but instead used the CreateAnonymous method to create an Anonymous Variable for the ControllerContext, but this way is slightly more succinct.

In unit testing an important step is to exercise the SUT. The member you want to invoke is often a method that takes one or more parameters, but in some test cases you don't care about the values of those parameters – you just want to invoke the method.

You can always make up one or more Dummy parameters and pass them to the method in question, but you could also use one of AutoFixture's Do convenience methods. There are several overloads that all take delegates that specify the action in question while providing you with Dummies of any parameters you don't care about.

A good example is WPF's ICommand interface. The most prevalent method is the Execute method that takes a single parameter parameter:

Most of the time we don't really care about the parameter because we only care that the command was invoked. However, we still need to supply a value for the parameter when we unit test our ICommand implementations. Obviously, we could just pass in a new System.Object every time, but why not let AutoFixture take care of that for us?

(You may think that new'ing up a System.Object is something you can easily do yourself, but imagine other APIs that require much more complex input parameters, and you should begin to see the potential.)

Here's a state-based unit test that verifies that the Message property of the MyViewModel class has the correct value after the FooCommand has been invoked:

Notice how the Do method takes an Action<object> to specify the method to invoke. AutoFixture automatically supplies an instance for the parameter parameter using the same engine to create Anonymous variables that it uses for everything else.

The Do method in question is really a generic method with this signature:

There are also overloads that take two, three or four input parameters, corresponding to the available Action types available in the BCL.

These methods are simply convenience methods that allow you to express your test code more succinctly than you would otherwise have been able to do.

A few months ago I described how you can use AutoFixture's With method to assign property values as part of building up an anonymous variable. In that scenario, the With method is used to explicitly assign a particular, pre-defined value to a property.

There's another overload of the With method that doesn't take an explicit value, but rather uses AutoFixture to create an anonymous value for the property. So what's the deal with that if AutoFixture's default behavior is to assign anonymous values to all writable properties?

In short it's an opt-in mechanism that only makes sense if you decide to opt out of the AutoProperties features.

As always, let's look at an example. This time, I've decided to show you a slightly more realistic example so that you can get an idea of how AutoFixture can be used to aid in unit testing. This also means that the example is going to be a little more complex than usual, but it's still simple.

Imagine that we wish to test that an ASP.NET MVC Controller Action returns the correct result. More specifically, we wish to test that the Profile method on MyController returns a ViewResult with the correct Model (the current user's name, to make things interesing).

Here's the entire test. It may look more complicated than it is – it's really only 10 lines of code, but I had to break them up to prevent unpleasant wrapping if your screen is narrow.

[TestMethod]

            public
            void ProfileWillReturnResultWithCorrectUserName()

{

    //
Fixture setup

    var fixture
= newFixture();

    fixture.Customize<ControllerContext>(ob
=> ob

        .OmitAutoProperties()

        .With(cc => cc.HttpContext));

    var expectedUserName
= 

        fixture.CreateAnonymous("UserName");

    var httpCtxStub
= newMock<HttpContextBase>();

    httpCtxStub.SetupGet(x => x.User).Returns(

        newGenericPrincipal(

            newGenericIdentity(expectedUserName), null));

    fixture.Register(httpCtxStub.Object);

    var sut
= fixture.Build<MyController>()

        .OmitAutoProperties()

        .With(c => c.ControllerContext)

        .CreateAnonymous();

    //
Exercise system

    ViewResult result
= sut.Profile();

    //
Verify outcome

    var actual
= result.ViewData.Model;

    Assert.AreEqual(expectedUserName,
actual, "User");

    //
Teardown

}

Apart from AutoFixture, I'm also making use of Moq to stub out HttpContextBase.

You can see the Anonymous With method in two different places: in the call to Customize and when the SUT is being built. In both cases you can see that the call to With follows a call to OmitAutoProperties. In other words: we are telling AutoFixture that we don't want any of the writable properties to be assigned a value except the one we identify.

Let me highlight some parts of the test.

fixture.Customize<ControllerContext>(ob
=> ob

    .OmitAutoProperties()

    .With(cc => cc.HttpContext));

This line of code instructs AutoFixture to always create a ControllerContext in a particular way: I don't want to use AutoProperties here, because ControllerContext has a lot of writable properties of abstract types, and that would require me to set up a lot of Test Doubles if I had to assign values to all of those. It's much easier to simply opt out of this mechanism. However, I would like to have the HttpContext property assigned, but I don't care about the value in this statement, so the With method simply states that AutoFixture should assign a value according to whatever rule it has for creating instances of HttpContextBase.

I can now set up a Stub that populates the User property of HttpContextBase:

            var httpCtxStub
= newMock<HttpContextBase>();

httpCtxStub.SetupGet(x => x.User).Returns(

    newGenericPrincipal(

        newGenericIdentity(expectedUserName), null));

fixture.Register(httpCtxStub.Object);

This is registered with the fixture instance which closes the loop to the previous customization.

I can now create an instance of my SUT. Once more, I don't want to have to set up a lot of irrelevant properties on MyController, so I opt out of AutoProperties and then explicitly opt in on the ControllerContext. This will cause AutoFixture to automatically populate the ControllerContext with the HttpContext Stub:

            var sut
= fixture.Build<MyController>()

    .OmitAutoProperties()

    .With(c => c.ControllerContext)

    .CreateAnonymous();

For completeness' sake, here's the MyController class that I am testing:

            public
            class
            MyController : Controller

{

    publicViewResult Profile()

    {

        object userName
= this.User.Identity.Name;

        returnthis.View(userName);

    }

}

This test may seem complex, but it really accomplishes a lot in only 10 lines of code, considering that ASP.NET MVC Controllers with a working HttpContext are not particularly trivial to set up.

In summary, this With method overload lets you opt in on one or more explicitly identified properties when you have otherwise decided to omit AutoProperties. As all the other Builder methods, this method can also be chained.

If you are doing Rich UI, INotifyPropertyChanged is a pretty important interface. This is as true for WPF as it was for Windows Forms. Consisting solely of an event, it's not any harder to unit test than other events.

You can certainly write each test manually like the following.

[TestMethod]

            public
            void ChangingMyPropertyWillRaiseNotifyEvent_Classic()

{

    //
Fixture setup

    bool eventWasRaised
= false;

    var sut
= newMyClass();

    sut.PropertyChanged += (sender, e) =>

        {

            if (e.PropertyName
== "MyProperty")

            {

                eventWasRaised = true;

            }

        };

    //
Exercise system

    sut.MyProperty = "Some
new value";

    //
Verify outcome

    Assert.IsTrue(eventWasRaised, "Event
was raised");

    //
Teardown

}

Even for a one-off test, this one has a few problems. From an xUnit Test Patterns point of view, there's the issue that the test contains conditional logic, but that aside, the main problem is that if you have a lot of properties, writing all these very similar tests become old hat very soon.

To make testing INotifyPropertyChanged events easier, I created a simple fluent interface that allows me to write the same test like this:

[TestMethod]

            public
            void ChangingMyPropertyWillRaiseNotifyEvent_Fluent()

{

    //
Fixture setup

    var sut
= newMyClass();

    //
Exercise system and verify outcome

    sut.ShouldNotifyOn(s => s.MyProperty)

        .When(s => s.MyProperty = "Some
new value");

    //
Teardown

}

You simply state for which property you want to verify the event when a certain operation is invoked. This is certainly more concise and intention-revealing than the previous test.

If you have interdependent properties, you can specify than an event was raised when another property was modified.

[TestMethod]

            public
            void ChangingMyPropertyWillRaiseNotifyForDerived()

{

    //
Fixture setup

    var sut
= newMyClass();

    //
Exercise system and verify outcome

    sut.ShouldNotifyOn(s => s.MyDerivedProperty)

        .When(s => s.MyProperty = "Some
new value");

    //
Teardown

}

The When method takes any Action<T>, so you can also invoke methods, use Closures and what not.

There's also a ShouldNotNotifyOn method to verify that an event was not raised when a particular operation was invoked.

This fluent interface is implemented with an extension method on INotifyPropertyChanged, combined with a custom class that performs the verification. Here are the extension methods:

            public
            static
            class
            NotifyPropertyChanged
          

{

    publicstaticNotifyExpectation<T>

        ShouldNotifyOn<T, TProperty>(this T
owner,

        Expression<Func<T,
TProperty>> propertyPicker) 

        where T
: INotifyPropertyChanged

    {

        returnNotifyPropertyChanged.CreateExpectation(owner,

            propertyPicker, true);

    }

    publicstaticNotifyExpectation<T> 

        ShouldNotNotifyOn<T, TProperty>(this T
owner,

        Expression<Func<T,
TProperty>> propertyPicker)

        where T
: INotifyPropertyChanged

    {

        returnNotifyPropertyChanged.CreateExpectation(owner,

            propertyPicker, false);

    }

    privatestaticNotifyExpectation<T>

        CreateExpectation<T, TProperty>(T owner,

        Expression<Func<T,
TProperty>> pickProperty,

        bool eventExpected) where T
: INotifyPropertyChanged

    {

        string propertyName
=

            ((MemberExpression)pickProperty.Body).Member.Name;

        returnnewNotifyExpectation<T>(owner,

            propertyName, eventExpected);

    }

}

And here's the NotifyExpectation class returned by both extension methods:

            public
            class
            NotifyExpectation<T>

    where T
: INotifyPropertyChanged

{

    privatereadonly T
owner;

    privatereadonlystring propertyName;

    privatereadonlybool eventExpected;

    public NotifyExpectation(T
owner,

        string propertyName, bool eventExpected)

    {

        this.owner
= owner;

        this.propertyName
= propertyName;

        this.eventExpected
= eventExpected;

    }

    publicvoid When(Action<T>
action)

    {

        bool eventWasRaised
= false;

        this.owner.PropertyChanged
+= (sender, e) =>

        {

            if (e.PropertyName
== this.propertyName)

            {

                eventWasRaised = true;

            }

        };

        action(this.owner);

        Assert.AreEqual<bool>(this.eventExpected,

            eventWasRaised,

            "PropertyChanged
on {0}", this.propertyName);

    }

}

You can replace the Assertion with one that matches your test framework of choice (this one was written for MSTest).

Since AutoFixtureis a Test Data Builder, one of its most important tasks is to build up graphs of fully populated, yet semantically correct, strongly typed objects. As such, its default behavior is to assign a value to every writable property in the object graph.

While this is sometimes the desired behavior, at other times it is not.

This is particularly the case when you want to test that a newly created object has a property of a particular value. When you want to test the default value of a writable property, AutoFixture's AutoProperty feature is very much in the way.

Let's consider as an example a piece of software that deals with vehicle registration. By default, a vehicle should have four wheels, since this is the most common occurrence. Although I always practice TDD, I'll start by showing you the Vehicle class to illustrate what I mean.

            public
            class
            Vehicle
          

{

    public Vehicle()

    {

        this.Wheels
= 4;

    }

    publicint Wheels
{ get; set; }

}

Here's a test that ensures that the default number of wheels is 4 – or does it?

In fact the assertion fails because the actual value is 1, not 4.

[TestMethod]

            public
            void AnonymousVehicleHasWheelsAssignedByFixture()

{

    //
Fixture setup

    var fixture
= newFixture();

    var sut
= fixture.CreateAnonymous<Vehicle>();

    //
Exercise system

    var result
= sut.Wheels;

    //
Verify outcome

    Assert.AreEqual<int>(4,
result, "Wheels");

    //
Teardown

}

Why does the test fail when the value of Wheels is set to 4 in the constructor? It fails because AutoFixture is designed to create populated test data, so it assigns a value to every writable property. Wheels is a writable property, so AutoFixture assigns an integer value to it using its default algorithm for creating anonymous numbers. Since no other numbers are being created during this test, the number assigned to Wheels is 1. This is AutoFixture's AutoProperties feature in effect.

When you want to test constructor logic, or otherwise wish to disable the AutoProperties feature, you can use a customized Builder with the OmitAutoProperties method:

[TestMethod]

            public
            void VehicleWithoutAutoPropertiesWillHaveFourWheels()

{

    //
Fixture setup

    var fixture
= newFixture();

    var sut
= fixture.Build<Vehicle>()

        .OmitAutoProperties()

        .CreateAnonymous();

    //
Exercise system

    var result
= sut.Wheels;

    //
Verify outcome

    Assert.AreEqual<int>(4,
result, "Wheels");

    //
Teardown

}

The OmitAutoProperties method instructs AutoFixture to skip assigning automatic Anonymous Values to all writable properties in the object graph. Any properties specifically assigned by the With method will still be assigned.

The test using OmitAutoProperties succeeds.

Some time ago, my good friend Martin Gildenpfennig from Ative made me aware that AutoFixture (among other things) is an generic implementation of the Test Data Builder pattern, and indeed it is.

In the original Gang of Four definition of a Design Pattern, several people must independently have arrived at the same general solution to a given problem before we can call a coding idiom a true Pattern. In this spirit, the Test Data Builder pattern is on the verge of becoming a true Design Pattern, since I came up with AutoFixture without having heard about Test Data Builder :)

The problem is the same: How do we create semantically correct test objects in a manner that is flexible and yet hides away irrelevant complexity?

Like others before me, I tried the Object Mother (anti?)pattern and found it lacking. To me the answer was AutoFixture, a library that heuristically builds object graphs using Reflection and built-in rules for specific types.

Although my original approach was different, you can certainly use AutoFixture as a generic Test Data Builder.

To demonstrate this, let's work with this (oversimplified) Order object model:

Assuming that we have an instance of the Fixture class (called fixture), we can create a new instance of the Order class with a ShippingAddress in Denmark:

            var order
= fixture.Build<Order>()

    .With(o => o.ShippingAddress, 

        fixture.Build<Address>()

        .With(a => a.Country, "Denmark")

        .CreateAnonymous())

    .CreateAnonymous();

While this works and follows the Test Data Builder pattern, I find this more concise and readable:

            var order
= fixture.CreateAnonymous<Order>();

order.ShippingAddress.Country = "Denmark";

The result is the same.

We can also add anonymous order lines to the order using this fluent interface:

            var order
= fixture.Build<Order>()

    .Do(o => fixture.AddManyTo(o.OrderLines))

    .CreateAnonymous();

but again, I find it easier to simply let AutoFixture create a fully anonymous Order instance, and then afterwards modify the relevant parts:

            var order
= fixture.CreateAnonymous<Order>();

fixture.AddManyTo(order.OrderLines);

Whether you prefer one style over the other, AutoFixture supports them both.

When I talk with people about TDD and unit testing, the discussion often moves into the area of Testability – that is, the software's susceptibility to unit testing. A couple of years back, Roy even discussed the seemingly opposable forces of Object-Oriented Design and Testability.

Lately, it has been occurring to me that there really isn't any conflict. Encapsulation is important because it manifests expert knowledge so that other developers can effectively leverage that knowledge, and it does so in a way that minimizes misuse.

However, too much encapsulation goes against the Open/Closed Principle (that states that objects should be open for extension, but closed for modification). From a Testability perspective, the Open/Closed Principle pulls object-oriented design in the desired direction. Equivalently, done correctly, making your API Testable is simply opening it up for extensibility.

As an example, consider a simple WPF ViewModel class called MainWindowViewModel. This class has an ICommand property that, when invoked, should show a message box. Showing a message box is good example of breaking testability, because if the SUT were to show a message box, it would be very hard to automatically verify and we wouldn't have fully automated tests.

For this reason, we need to introduce an abstraction that basically models an action with a string as input. Although we could define an interface for that, an Action<string> fits the bill perfectly.

To enable that feature, I decide to use Constructor Injection to inject that abstraction into the MainWindowViewModel class:

            public MainWindowViewModel(Action<string>
notify)

{

    this.ButtonCommand
= newRelayCommand(p
=> 

    { notify("Button
was clicked!"); });

}

When I recently did that at a public talk I gave, one member of the audience initially reacted by assuming that I was now introducing test-specific code into my SUT, but that's not the case.

What I'm really doing here is opening the MainWindowViewModel class for extensibility. It can still be used with message boxes:

            var vm
= newMainWindowViewModel(s
=> MessageBox.Show(s));

but now we also have the option of notifying by sending off an email; writing to a database; or whatever else we can think of.

It just so happens that one of the things we can do instead of showing a message box, is unit testing by passing in a Test Double.

            //
Fixture setup
          

            var mockNotify
= 

    MockRepository.GenerateMock<Action<string>>();

mockNotify.Expect(a => a("Button
was clicked!"));

            var sut
= newMainWindowViewModel(mockNotify);

            //
Exercise system
          

sut.ButtonCommand.Execute(newobject());

            //
Verify outcome
          

mockNotify.VerifyAllExpectations();

            //
Teardown
          

Once again, TDD has lead to better design. In this case it prompted me to open the class for extensibility. There really isn't a need for Testability as a specific concept; the Open/Closed Principle should be enough to drive us in the right direction.

Pragmatically, that's not the case, so we use TDD to drive us towards the Open/Closed Principle, but I think it's important to note that we are not only doing this to enable testing: We are creating a better and more flexible API at the same time.

Dear reader, I hope you are still with me!

After eight posts of AutoFixture feature walkthroughs, I can't blame you for wondering why this tool might even be relevant to you. In this post, we'll finally begin to look at how AutoFixture can help you towards Zero-Friction TDD!

In an earlier post, I described how the Fixture Object pattern can help you greatly reduce the amount of test code that you have to write. Since AutoFixture was designed to act as a general-purpose Fixture Object, it can help you reduce the amount of test code even further, letting you focus on specifying the behavior of your SUT.

In that former post, the original example was this complex test that I will repeat in it's entirety for your benefit (or horror):

[TestMethod]

            public
            void NumberSumIsCorrect_Naïve()

{

    //
Fixture setup

    Thing thing1
= newThing()

    {

        Number = 3,

        Text = "Anonymous
text 1"

    };

    Thing thing2
= newThing()

    {

        Number = 6,

        Text = "Anonymous
text 2"

    };

    Thing thing3
= newThing()

    {

        Number = 1,

        Text = "Anonymous
text 3"

    };

    int expectedSum
= new[] { thing1, thing2, thing3 }.

        Select(t => t.Number).Sum();

    IMyInterface fake
= newFakeMyInterface();

    fake.AddThing(thing1);

    fake.AddThing(thing2);

    fake.AddThing(thing3);

    MyClass sut
= newMyClass(fake);

    //
Exercise system

    int result
= sut.CalculateSumOfThings();

    //
Verify outcome

    Assert.AreEqual<int>(expectedSum,
result,

        "Sum
of things");

    //
Teardown

}

This test consists of 18 lines of code.

Using the Fixture Object pattern, I was able to cut that down to 7 lines of code, which is a 61% improvement (however, the downside was an additional 19 lines of (reusable) code for MyClassFixture, so the benefit can only be reaped when you have multiple tests leveraged by the same Fixture Object. This was all covered in the former post, to which I will refer you).

With AutoFixture, we can do much better. Here's a one-off rewrite of the unit test using AutoFixture:

[TestMethod]

            public
            void NumberSumIsCorrect_AutoFixture()

{

    //
Fixture setup

    Fixture fixture
= newFixture();

    IMyInterface fake
= newFakeMyInterface();

    fixture.Register<IMyInterface>(()
=> fake);

    var things
= fixture.CreateMany<Thing>().ToList();

    things.ForEach(t => fake.AddThing(t));

    int expectedSum
= things.Select(t => t.Number).Sum();

    MyClass sut
= fixture.CreateAnonymous<MyClass>();

    //
Exercise system

    int result
= sut.CalculateSumOfThings();

    //
Verify outcome

    Assert.AreEqual<int>(expectedSum,
result,

        "Sum
of things");

    //
Teardown

}

In this test, I map the concrete fake instance to the IMyInterface type in the fixture object, and then use its ability to create many anonymous instances with one method call. Before exercising the SUT, I also use the fixture instance as a SUT Factory.

Apart from AutoFixture (and FakeMyInterface, which is invariant for all variations, and thus kept out of the comparison), this test stands alone, but still manages to reduce the number of code lines to 10 lines – a 44% improvement! In my book, that's already a significant gain in productivity and maintainability, but we can do better!

If we need to test MyClass repeatedly in similar ways, we can move the common code to a Fixture Object based on AutoFixture, and the test can be refactored to this:

[TestMethod]

            public
            void NumberSumIsCorrect_DerivedFixture()

{

    //
Fixture setup

    MyClassFixture fixture
= newMyClassFixture();

    fixture.AddManyTo(fixture.Things);

    int expectedSum
= 

        fixture.Things.Select(t => t.Number).Sum();

    MyClass sut
= fixture.CreateAnonymous<MyClass>();

    //
Exercise system

    int result
= sut.CalculateSumOfThings();

    //
Verify outcome

    Assert.AreEqual<int>(expectedSum,
result,

        "Sum
of things");

    //
Teardown

}

Now we are back at 7 lines of code, which is on par with the original Fixture Object-based test, but now MyClassFixture is reduced to 8 lines of code:

            internal
            class
            MyClassFixture : Fixture

{

    internal MyClassFixture()

    {

        this.Things
= newList<Thing>();

        this.Register<IMyInterface>(()
=>

            {

                var fake
= newFakeMyInterface();

                this.Things.ToList().ForEach(t
=>

                    fake.AddThing(t));

                return fake;

            });

    }

    internalIList<Thing>
Things { get; privateset;
}

}

Notice how I've moved the IMyInterface-to-FakeMyInterface mapping to MyClassFixture. Whenever it's asked to create a new instance of IMyInterface, MyClassFixture makes sure to add all the Thing instances to the fake before returning it.

Compared to the former Fixture Object of 19 lines, that's another 58% improvement. Considering some of the APIs I encounter in my daily work, the above example is even rather simple. The more complex and demanding your SUT's API is, the greater the gain from using AutoFixture will be, since it's going to figure out much of the routine stuff for you.

With this post, I hope I have given you a taste of the power that AutoFixture provides. It allows you to focus on specifying the behavior of your SUT, while taking care of all the infrastructure tedium that tends to get in the way.

At May 12 2009 I'll be speaking at 7N's IT Konference 2009 (in Danish, so that's no spelling error). You can read the program here.

The topic of my talk will be TDD patterns and terminology, so I'll discuss Fixtures, Stubs, Mocks and the like. As always, xUnit Test Patterns will form the basis of my vocabulary.

Of the other speakers, I'm particularly looking forward to hear my good friend Martin Gildenpfennig from Ative speak!

It gives me great pleasure to announce my latest project: AutoFixture!

What is AutoFixture?

In essence, AutoFixture is a library that creates Anonymous Variables for you when you write unit tests. The intention is that it should enhance your productivity when you do Test-Driven Development – as it has done mine.

Instead of using mental resources on creating Anonymous Variables, AutoFixture can do it for you. By default, it uses Constrained Non-Determinism, but you can configure it to behave differently if you wish.

Here’s a very basic example:

[TestMethod]

            public
            void IntroductoryTest()

{

    //
Fixture setup

    Fixture fixture
= newFixture();

    int expectedNumber
= fixture.CreateAnonymous<int>();

    MyClass sut
= fixture.CreateAnonymous<MyClass>();

    //
Exercise system

    int result
= sut.Echo(expectedNumber);

    //
Verify outcome

    Assert.AreEqual<int>(expectedNumber,
result, "Echo");

    //
Teardown

}

The Fixture class is your main entry point to AutoFixture. You can use it as is, customize it, or derive from it as you please; it makes a great base class for a Fixture Object.

The expectedNumber variable may be an Explicit Expectation, but its value is Anonymous, so instead of coming up with a number ourselves, we can let the CreateAnonymous<T> method do it for us.

This method can create instances of most CLR types as long as they have a public constructor (it uses Reflection), but for many primitive types (like Int32), it has specific, customizable algorithms for creating values using Constrained Non-Determinism.

When creating the SUT, we can also use Fixture as an excellent SUT Factory. Since it will do whatever it can to create an instance of the type you ask for, it is pretty robust if you decide to refactor the SUT’s constructor.

The above example only hints at what AutoFixture can do. Since the example is very simple, it may be hard to immediately understand its value, so in future posts I will expand on specific AutoFixture features and principles.

Getting started with AutoFixture is as simple as downloading it from CodePlex and referencing the assembly in Visual Studio.

(A Zero-Friction TDD post)

For a simple API, setting up the Fixture may be as simple as creating a new instance of the SUT, and possibly any Expected or Anonymous Variables. On the other hand, for a complex API, setting up the fixture may require quite a bit of (potentially repetitive) code.

Since the DRY principle also applies to test code, it quickly becomes necessary to create test-specific helper methods and other SUT API Encapsulation, and I've found that instead of creating a more or less unplanned set of disconnected helper methods, it's much cleaner (and, not to mention, much more object-oriented) to create a single object that represents the Fixture, and attach the helper methods to this object.

Let's look at an example.

Here's a unit test with a complex Fixture Setup:

[TestMethod]

            public
            void NumberSumIsCorrect_Naïve()

{

    //
Fixture setup

    Thing thing1
= newThing()

    {

        Number = 3,

        Text = "Anonymous
text 1"

    };

    Thing thing2
= newThing()

    {

        Number = 6,

        Text = "Anonymous
text 2"

    };

    Thing thing3
= newThing()

    {

        Number = 1,

        Text = "Anonymous
text 3"

    };

    int expectedSum
= new[] { thing1, thing2, thing3 }.

        Select(t => t.Number).Sum();

    IMyInterface fake
= newFakeMyInterface();

    fake.AddThing(thing1);

    fake.AddThing(thing2);

    fake.AddThing(thing3);

    MyClass sut
= newMyClass(fake);

    //
Exercise system

    int result
= sut.CalculateSumOfThings();

    //
Verify outcome

    Assert.AreEqual<int>(expectedSum,
result,

        "Sum
of things");

    //
Teardown

}

If this was a truly one-off test and you know with certainty that there's going to be no other tests just remotely similar to this one, just hard-coding the entire Fixture Setup inline is in order, but as soon as the need for similar tests arises, this approach leads to repetitive code, and hence unmaintainable tests.

The more repetitive code that can be delegated to helper methods the better. A common refactoring of the previous test might then look something like this:

[TestMethod]

            public
            void NumberSumIsCorrect_Helpers()

{

    //
Fixture setup

    Thing thing1
= MyClassTest.CreateAnonymousThing();

    Thing thing2
= MyClassTest.CreateAnonymousThing();

    Thing thing3
= MyClassTest.CreateAnonymousThing();

    Thing[]
things = new[] { thing1, thing2, thing3 };

    int expectedSum
= things.Select(t => t.Number).Sum();

    IMyInterface fake
= newFakeMyInterface();

    MyClassTest.AddThingsToMyInterface(fake,
things);

    MyClass sut
= newMyClass(fake);

    //
Exercise system

    int result
= sut.CalculateSumOfThings();

    //
Verify outcome

    Assert.AreEqual<int>(expectedSum,
result,

        "Sum
of things");

    //
Teardown

}

While this is better, the helper methods are static methods, so it's necessary to pass too much state around. The array of Things and the fake is both needed in the test itself, as well as in the AddThingsToMyInterface helper method.

By moving and refactoring the helper methods to a new class that represents the Fixture, the test code becomes both more reusable and more readable.

[TestMethod]

            public
            void NumberSumIsCorrect_FixtureObject()

{

    //
Fixture setup

    MyClassFixture fixture
= newMyClassFixture();

    fixture.AddAnonymousThings();

    int expectedSum
= 

        fixture.Things.Select(t => t.Number).Sum();

    MyClass sut
= fixture.CreateSut();

    //
Exercise system

    int result
= sut.CalculateSumOfThings();

    //
Verify outcome

    Assert.AreEqual<int>(expectedSum,
result,

        "Sum
of things");

    //
Teardown

}

The MyClassFixture instance now holds the state of the Fixture, so there's much less need to pass around as much data as before. The set of Things is now contained within the Fixture object itself, and the fake has totally disappeared from the test; it's still present, but now encapsulated within MyClassFixture.

            internal
            class
            MyClassFixture
          

{

    public MyClassFixture()

    {

        this.Fake
= newFakeMyInterface();

        this.Things
= newList<Thing>();

    }

    internalFakeMyInterface Fake
{ get; privateset;
}

    internalIList<Thing>
Things { get; privateset;
}

    internalvoid AddAnonymousThings()

    {

        int many
= 3;

        for (int i
= 0; i < many; i++)

        {

            Thing t
= this.CreateAnonymousThing();

            this.Things.Add(t);

            this.Fake.AddThing(t);

        }

    }

    internalMyClass CreateSut()

    {

        returnnewMyClass(this.Fake);

    }

    privateThing CreateAnonymousThing()

    {

        Thing t
= newThing();

        t.Number = this.Things.Count
+ 1;

        t.Text = Guid.NewGuid().ToString();

        return t;

    }

}

The CreateAnonymousThing method uses Constrained Non-Determinism to create unique Thing instances. The AddAnonymousThings method uses 3 as an equivalence of many, and the CreateSut method acts as a SUT Factory.

This is both more reusable and more expressive than a collection of disjointed static helper methods.

Whenever I begin to feel that setting up a Test Fixture is becoming too cumbersome, Fixture Object is the first pattern I consider.

In the last couple of years, there’s been a lot of debate in the community on the philosophy behind TDD and where to put the emphasis – even to the point of debating whether the acronym stands for Test-Driven Development or Test-Driven Design.

Other people don’t like the emphasis on tests, since that makes TDD sound like a Testing discipline, and not a Development discipline. Instead, they prefer terms like Example-Driven Design/Development (EDD) or even Design by Example (DbE).

This view seems to me to be particularly prevalent in Microsoft, where there’s a rather sharp distinction between developers and testers (job titles to the contrary) – I guess that’s one of the reasons why xUnit.net (a project initiated by Microsoft employees) uses the attribute Fact instead of Test or TestMethod.

For people used to SCRUM or other agile methodologies, this distinction is more blurred, and they also seem to accept the T in TDD more willingly.

However, the adherents of EDD claim that the mere presence of the word test make some developers block any further input and stop listening. They may be right in that.

They also claim that the tests in TDD/EDD are nothing more than accidental artifacts of the development process, and hence argue that we shouldn’t call them tests at all. However, if that’s true, this little story related by Ayende must be an example of EDD in its purest form :)

To me, the tests are also important. Since 2003 I’ve been practicing TDD, and while I love how it helps me arrive at better design, I also savor the safety net that my suite of tests gives me. The tests that I write during TDD define the behavior of the software. In many cases, I’d even claim that such a regression test suite is more valuable than a Quality Assurance (QA) regression test suite – after all, a QA suite may catch some edge cases, but they don’t focus on the intended behavior of the system, but often more on how to break it - but I digress…

My recent posts on Executable Specification and Constrained Non-Determinism help explain my current stance in this debate: In my opinion, EDD fails to establish a relationship by not providing Derived Values. After all, what does a test like the following specify?

[TestMethod]

            public
            void InvertWillReverseText_Naïve()

{

    //
Fixture setup

    MyClass sut
= newMyClass();

    //
Exercise system

    string result
= sut.Invert("ploeh");

    //
Verify outcome

    Assert.AreEqual<string>("heolp",
result, "Invert");

    //
Teardown

}

How would you implement the Invert method? Here’s one possible implementation:

            return
            "heolp";

Obviously, you could now write a new test that gives a second example of input and outcome and force me to write a more sophisticated algorithm. However, with only two examples, I might still be tempted to write a switch statement with some hard-coded return values until you’ve written so many ‘examples’ that you’ve coerced me into writing the more general (and correct) algorithm.

Such an approach I find inefficient.

Instead, by using Constrained Non-Determinism to force myself to define Derived Values, each test fully specifies the desired behavior. It doesn’t provide examples. It provides the specification, and instead of having to write several similar examples to coerce a general algorithm to emerge, I can usually nail it in a single test.

This approach could be styled Specification-Driven Development, and that’s how I’ve been writing code for the last year or so.

This may turn out to be the most controversial of my Zero-Friction TDD posts so far, as it supposedly goes against conventional wisdom. However, I have found this approach to be really powerful since I began using it about a year ago.

In my previous post, I explained how Derived Values help ensure that tests act as Executable Specification. In short, a test should clearly specify the relationship between input and outcome, as this test does:

[TestMethod]

            public
            void InvertWillReverseText()

{

    //
Fixture setup

    string anonymousText
= "ploeh";

    string expectedResult
=

        newstring(anonymousText.Reverse().ToArray());

    MyClass sut
= newMyClass();

    //
Exercise system

    string result
= sut.Invert(anonymousText);

    //
Verify outcome

    Assert.AreEqual<string>(expectedResult,
result,

        "DoWork");

    //
Teardown

}

However, it is very tempting to just hardcode the expected value. Consistently using Derived Values to establish the relationship between input and outcome requires discipline.

To help myself enforce this discipline, I use well-defined, but essentially random, input, because when the input is random, I don't know the value at design time, and hence, it is impossible for me to accidentally hard-code any assertions.

[TestMethod]

            public
            void InvertWillReverseText_Cnd()

{

    //
Fixture setup

    string anonymousText
= Guid.NewGuid().ToString();

    string expectedResult
=

        newstring(anonymousText.Reverse().ToArray());

    MyClass sut
= newMyClass();

    //
Exercise system

    string result
= sut.Invert(anonymousText);

    //
Verify outcome

    Assert.AreEqual<string>(expectedResult,
result,

        "DoWork");

    //
Teardown

}

For strings, I prefer Guids, as the above example demonstrates. For numbers, I often just use the sequence of natural numbers (i.e. 1, 2, 3, 4, 5...). For booleans, I often use an alternating sequence (i.e. true, false, true, false...).

While this technique causes input to become non-deterministic, I always pick the non-deterministic value-generating algorithm in such a way that it creates 'nice' values; I call this principle Constrained Non-Determinism. Values are carefully generated to stay far away from any boundary conditions that may cause the SUT to behave differently in each test run.

Conventional unit testing wisdom dictates that unit tests should be deterministic, so how can I possibly endorse this technique?

To understand this, it's important to know why the rule about deterministic unit tests exist. It exists because we want to be certain that each time we execute a test suite, we verify the exact same behavior as we did the last time (given that no tests changed). Since we also use test suites as regression tests, it's important that we can be confident that each and every test run verifies the exact same specification.

Constrained Non-Determinism doesn't invalidate that goal, because the algorithm that generates the values must be carefully picked to always create values that stay within the input's Equivalence Class.

In a surprisingly large set of APIs, strings, for example, are treated as opaque values that don't influence behavior in themselves. Many enterprise applications mostly store and read data from persistent data stores, and the value of a string in itself is often inconsequential from the point of view of the code's execution path. Data stores may have constraints on the length of strings, so Constrained Non-Determinism dictates that you should pick the generating algorithm so that the string length always stays within (or exceeds, if that's what you want to test) the constraint. Guid.ToString always returns a string with the length of 36, which is fine for a large number of scenarios.

Note that Constrained Non-Determinism is only relevant for Anonymous Variables. For input where the value holds a particular meaning in the context of the SUT, you will still need to hand-pick values as always. E.g. if the input is expected to be an XML string conforming to a particular schema, a Guid string makes no sense.

A secondary benefit of Constrained Non-Determinism is that you don't have to pause to come up with values for Anonymous Variables when you are writing the test.

While this advice may be controversial, I can only recommend it - I've been using this technique for about a year now, and have only become more fond of it as I have gained more experience with it.

In this Zero-Friction TDD post, I’d like to take a detour around the concept of tests as Executable Specification.

An important aspect of test maintainability is readability. Tests should act both as Executable Specification as well as documentation, which puts a lot of responsibility on the test.

One facet of test readability is to make the relationship between the Fixture, the SUT and the verification as easy to understand as possible. In other words, it should be clear to the Test Reader what is being asserted, and why.

Consider a test like this one:

[TestMethod]

            public
            void InvertWillReverseText_Naïve()

{

    //
Fixture setup

    MyClass sut
= newMyClass();

    //
Exercise system

    string result
= sut.Invert("ploeh");

    //
Verify outcome

    Assert.AreEqual<string>("heolp",
result, "DoWork");

    //
Teardown

}

Since this test is so simple, I expect that you can easily figure out that it implies that the Invert method should simply reverse its input argument, but one of the reasons this seems to be evident is because of the proximity of the two strings, as well as the test’s name.

In a test of a more complex API, this may not be quite as evident.

[TestMethod]

            public
            void DoItWillReturnCorrectResult_Naïve()

{

    //
Fixture setup

    MyClass sut
= newMyClass();

    //
Exercise system

    int result
= sut.DoIt("ploeh");

    //
Verify outcome

    Assert.AreEqual<int>(42,
result, "DoIt");

    //
Teardown

}

In this test, there's no apparent relationship between the input (ploeh) and the output (42). Whatever the algorithm is behind the DoIt method, it's completely opaque to the Test Reader, and the test fails in its role as specification and documentation.

Returning to the first example, it would be better if the relationship between input and output was explicitly described:

[TestMethod]

            public
            void InvertWillReverseText()

{

    //
Fixture setup

    string anonymousText
= "ploeh";

    string expectedResult
=

        newstring(anonymousText.Reverse().ToArray());

    MyClass sut
= newMyClass();

    //
Exercise system

    string result
= sut.Invert(anonymousText);

    //
Verify outcome

    Assert.AreEqual<string>(expectedResult,
result,

        "DoWork");

    //
Teardown

}

In this case, the input and expected outcome are clearly related, and we call the expectedResult variable a Derived Value, since we explicitly derive the expected result from the input.

Note that I’m not asking you to re-implement the whole algorithm in the test, but only to establish a relationship. One of the main rules of thumb of unit testing is that a test should never contain conditional branches, so there must be at least one test case per path though the SUT.

In the example, the Invert method actually looks like this:

            public
            string Invert(string message)

{

    double d;

    if (double.TryParse(message, out d))

    {

        return (1d
/ d).ToString();

    }

    returnnewstring(message.Reverse().ToArray());

}

Note that the above test only reproduces that part of the algorithm that corresponds to the Equivalence Class defined by the input, whereas the branch that is triggered by a number string can be tested by another test case that doesn’t specify string reversion.

[TestMethod]

            public
            void InvertWillInvertNumber()

{

    //
Fixture setup

    double anonymousNumber
= 10;

    string numberText
= anonymousNumber.ToString();

    string expectedResult
= 

        (1d / anonymousNumber).ToString();

    MyClass sut
= newMyClass();

    //
Exercise system

    string result
= sut.Invert(numberText);

    //
Verify outcome

    Assert.AreEqual<string>(expectedResult,
result,

        "DoWork");

    //
Teardown

}

In this way, we can break down the test cases to individual Executable Specifications that define the expected behavior for each Equivalence Class.

While such tests more clearly provide both specification and documentation, it requires discipline to write tests in this way. Particularly when the algorithm is so simple as is the case here, it's very tempting to just hard-code the values directly into the assertion.

In a future post, I’ll explain how we can force ourselves to do the right thing per default.

In my Zero-Friction TDD series, I focus on establishing a set of good habits that can potentially make you more productive while writing tests TDD style. While being able to quickly write good tests is important, this is not the only quality on which you should focus.

Maintainability, not only of your production code, but also of your test code, is important, and the DRY principle is just as applicable here.

Consider a test like this:

[TestMethod]

            public
            void SomeTestUsingConstructorToCreateSut()

{

    //
Fixture setup

    MyClass sut
= newMyClass();

    //
Exercise system

    //
...

    //
Verify outcome

    //
...

    //
Teardown

}

Such a test represents an anti-pattern you can easily fall victim to. The main item of interest here is that I create the SUT using its constructor. You could say that I have hard-coded this particular constructor usage into my test.

This is not a problem if there's only one test of MyClass, but once you have many, this starts to become a drag on your ability to refactor your code.

Imagine that you want to change the constructor of MyClass from the default constructor to one that takes a dependency, like this:

            public MyClass(IMyInterface dependency)

If you have many (in this case, not three, but dozens) tests using the default constructor, this simple change will force you to visit all these tests and modify them to be able to compile again.

If, instead, we use a factory to create the SUT in each test, there's a single place where we can go and update the creation logic.

[TestMethod]

            public
            void SomeTestUsingFactoryToCreateSut()

{

    //
Fixture setup

    MyClass sut
= MyClassFactory.Create();

    //
Exercise system

    //
...

    //
Verify outcome

    //
...

    //
Teardown

}

The MyClassFactory class is a test-specific helper class (more formally, it's part of our SUT API Encapsulation) that is part of the unit test project. Using this factory, we only need to modify the Create method to implement the constructor change.

            internal
            static
            MyClass Create()

{

    IMyInterface fake
= newFakeMyInterface();

    returnnewMyClass(fake);

}

Instead of having to modify many individual tests to support the signature change of the constructor, there's now one central place where we can go and do that. This pattern supports refactoring much better, so consider making this a habit of yours.

One exception to this rule concerns tests that explicitly deal with the constructor, such as this one:

[ExpectedException(typeof(ArgumentNullException))]

[TestMethod]

            public
            void CreateWithNullMyInterfaceWillThrow()

{

    //
Fixture setup

    IMyInterface nullMyInterface
= null;

    //
Exercise system

    newMyClass(nullMyInterface);

    //
Verify outcome (expected exception)

    //
Teardown

}

In a case like this, where you explicitly want to deal with the constructor in an anomalous way, I consider it reasonable to deviate from the rule of using a factory to create the SUT. Although this may result in a need to fix the SUT creation logic in more than one place, instead of only in the factory itself, it's likely to be constrained to a few places instead of dozens or more, since normally, you will only have a handful of these explicit constructor tests.

Compared to my Zero-Friction TDD tips and tricks, this particular advice has the potential to marginally slow you down. However, this investments pays off when you want to refactor your SUT's constructor, and remember that you can always just write the call to the factory and move on without implementing it right away.

In my original post on Zero-Friction TDD, I continually updated the list of posts in the series, so that there would always be a central 'table of contents' for this topic.

Since I'll lose the ability to keep editing any of my previous postings on the old ploeh blog, the present post now contains the most updated list of Zero-Friction TDD articles:

• Naming SUT Test Variables
• Naming Direct Output Variables
• Anonymous Variables
• Ignore Irrelevant Return Values
• testmethod Code Snippet
• 3 Is Many
• Why Use AreEqual<T>?
• Assert Messages Are Not Optional
• Use The Generate Method Stub Smart Tag To Stay In The Zone
• Test-Driven Properties
• SUT Factory
• Derived Values Ensure Executable Specification
• Constrained Non-Determinism
• Explicit Expectations
• Fixture Object
• AutoFixture As Fixture Object