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.

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.

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