Here’s a question I often get:

“Should I test my DI Container configuration?”

The motivation for asking mostly seems to be that people want to know whether or not their applications are correctly wired. That makes sense.

A related question I also often get is whether or not a particular container has a self-test feature? In this post I’ll attempt to answer both questions.

Container Self-testing

Some DI Containers have a method you can invoke to make it perform a consistency check on itself. As an example, StructureMap has the AssertConfigurationIsValid method that, according to documentation does “a full environment test of the configuration of [the] container.” It will “try to create every configured instance [...]”

Calling the method is really easy:

container.AssertConfigurationIsValid();

Such a self-test can often be an expensive operation (not only for StructureMap, but in general) because it’s basically attempting to create an instance of each and every Service registered in the container. If the configuration is large, it’s going to take some time, but it’s still going to be faster than performing a manual test of the application.

Two questions remain: Is it worth invoking this method? Why don’t all containers have such a method?

The quick answer is that such a method is close to worthless, which also explains why many containers don’t include one.

To understand the answer, consider the set of all components contained in the container in this figure:

The container contains the set of components IFoo, IBar, IBaz, Foo, Bar, Baz, and Qux so a self-test will try to create a single instance of each of these seven types. If all seven instances can be created, the test succeeds.

All this accomplishes is to verify that the configuration is internally consistent. Even so, an application could require instances of the ICorge, Corge or Grault types which are completely external to the configuration, in which case resolution would fail.

Even more subtly, resolution would also fail whenever the container is queried for an instance of IQux, since this interface isn’t part of the configuration, even though it’s related to the concrete Qux type which is registered in the container. A self-test only verifies that the concrete Qux class can be resolved, but it never attempts to create an instance of the IQux interface.

In short, the fact that a container’s configuration is internally consistent doesn’t guarantee that all services required by an application can be served.

Still, you may think that at least a self-test can constitute an early warning system: if the self-test fails, surely it must mean that the configuration is invalid? Unfortunately, that’s not true either.

If a container is being configured using Auto-registration/Convention over Configuration to scan one or more assemblies and register certain types contained within, chances are that ‘too many’ types will end up being registered – particularly if one or more of these assemblies are reusable libraries (as opposed to application-specific assemblies). Often, the number of redundant types added is negligible, but they may make the configuration internally inconsistent. However, if the inconsistency only affects the redundant types, it doesn’t matter. The container will still be able to resolve everything the current application requires.

Thus, a container self-test method is worthless.

Then how can the container configuration be tested?

Explicit Testing of Container Configuration

Since a container self-test doesn’t achieve the desired goal, how can we ensure that an application can be composed correctly?

One option is to write an automated integration test (not a unit test) for each service that the application requires. Still, if done manually, you run the risk of forgetting to write a test for a specific service. A better option is to come up with a convention so that you can identify all the services required by a specific application, and then write a convention-based test to verify that the container can resolve them all.

Will this guarantee that the application can be correctly composed?

No, it only guarantees that it can be composed – not that this composition is correct.

Even when a composed instance can be created for each and every service, many things may still be wrong:

• Composition is just plain wrong:
  • Decorators may be missing
  • Decorators may have been added in the wrong order
  • The wrong services are injected into consumers (this is more likely to happen when you follow the Reused Abstractions Principle, since there will be multiple concrete implementations of each interface)
• Configuration values like connection strings and such are incorrect – e.g. while a connection string is supplied to a constructor, it may not contain the correct values.
• Even if everything is correctly composed, the run-time environment may prevent the application from working. As an example, even if an injected connection string is correct, there may not be any connection to the database due to network or security misconfiguration.

In short, a Subcutaneous Test or full System Test is the only way to verify that everything is correctly wired. However, if you have good test coverage at the unit test level, a series of Smoke Tests is all that you need at the System Test level because in general you have good reason to believe that all behavior is correct. The remaining question is whether all this correct behavior can be correctly connected, and that tends to be an all-or-nothing proposition.

Conclusion

While it would be possible to write a set of convention-based integration tests to verify the configuration of a DI Container, the return of investment is too low since it doesn’t remove the need for a set of Smoke Tests at the System Test level.

There’s this meme going around that software reuse is a fallacy. Bollocks! The reuse is a fallacy meme is a fallacy :) To be fair, I’m not claiming that everything can and should be reused, but my claim is that all code produced by Test-Driven Development (TDD) is being reused. Here’s why:

When tests are written first, they act as a kind of REPL. Tests tease out the API of the SUT, as well as its behavior. In this point in the development process, the tests serve as a feedback mechanism. Only later, when the tests and the SUT stabilize, will the tests be repurposed (dare I say ‘reused’?) as regression tests. In other words: over time, tests written during TDD have more than one role:

1. Feedback mechanism
2. Regression test

Each test plays one of these roles at a time, but not both.

While the purpose of TDD is to evolve the SUT, the process produces two types of artifacts:

1. Tests
2. Production code

Notice how the tests appear before the production code, which is an artifact of the test code.

The unit tests are the first client of the production API.

When the production code is composed into an application, that application becomes the second client, so it reuses the API. This is a very beneficial effect of TDD, and probably one of the main reasons why TDD, if done correctly, produces code of high quality.

A colleague once told me (when referring to scale-out) that the hardest step is to go from one server to two servers, and I’ve later found that principle to apply much more broadly. Generalizing from a single case to two distinct cases is often the hardest step, and it becomes much easier to generalize further from two to an arbitrary number of cases.

This explains why TDD is such an efficient process. Apart from the beneficial side effect of producing a regression test suite, it also ensures that at the time the API goes into production, it’s already being shared (or reused) between at least two distinct clients. If, at a later time, it becomes necessary to add a third client, the hard part is already done.

TDD produces reusable code because the production application reuses the API which were realized by the tests.

Recently I had the inclination to do the Tennis Kata a couple of times. The first time I saw it I thought it wasn’t terribly interesting as an exercise in C# development. It would basically just be an application of the State pattern, so I decided to make it a bit more interesting. More or less by intuition I decided to give myself the following constraints:

• All types must be immutable
• All members must have a cyclomatic complexity of 1

Now that’s more interesting :)

Given these constraints, what would be the correct approach? Given that this is a finite state machine with a fixed number of states, the Visitor pattern will be a good match.

Each player’s score can be modeled as a Value Object that can be one of these types:

• ZeroPoints
• FifteenPoints
• ThirtyPoints
• FortyPoints
• AdvantagePoint
• GamePoint

All of these classes implement the IPoints interface:

public interface IPoints

{

    IPoints Accept(IPoints visitor);

    IPoints LoseBall();

    IPoints WinBall(IPoints opponentPoints);

    IPoints WinBall(AdvantagePoint opponentPoints);

    IPoints WinBall(FortyPoints opponentPoints);

}

The interesting insight here is that until the opponent's score reaches FortyPoints nothing special happens. Those states can be effectively collapsed into the WinBall(IPoints) method. However, when the opponent either has FortyPoints or AdvantagePoint, special things happen, so IPoints has specialized methods for those cases. All implementations should use double dispatch to invoke the correct overload of WinBall, so the Accept method must be implemented like this:

public IPoints Accept(IPoints visitor)

{

    return visitor.WinBall(this);

}

That’s the core of the Visitor pattern in action. When the implementer of the Accept method is either FortyPoints or AdvantagePoint, the specialized overload will be invoked.

It’s now possible to create a context around a pair of IPoints (called a Game) to implement a method to register that Player 1 won a ball:

public Game PlayerOneWinsBall()

{

    var newPlayerOnePoints = this.PlayerTwoScore

        .Accept(this.PlayerOneScore);

    var newPlayerTwoPoints = 

        this.PlayerTwoScore.LoseBall();

    return new Game(

        newPlayerOnePoints, newPlayerTwoPoints);

}

A similar method for player two simply reverses the roles. (I’m currently reading Lean Architecture, but have yet to reach the chapter on DCI. However, considering what I’ve already read about DCI, this seems to fit the bill pretty well… although I might be wrong on that account.)

The context calculates new scores for both players and returns the result as a new instance of the Game class. This keeps the Game and IPoints implementations immutable.

The new score for the winner depends on the opponent’s score, so the appropriate overload of WinBall should be invoked. The Visitor implementation makes it possible to pick the right overload without resorting to casts and if statements. As an example, the FortyPoints class implements the three WinBall overloads like this:

public IPoints WinBall(IPoints opponentPoints)

{

    return new GamePoint();

}

public IPoints WinBall(FortyPoints opponentPoints)

{

    return new AdvantagePoint();

}

public IPoints WinBall(AdvantagePoint opponentPoints)

{

    return this;

}

It’s also important to correctly implement the LoseBall method. In most cases, losing a ball doesn’t change the current state of the loser, in which case the implementation looks like this:

public IPoints LoseBall()

{

    return this;

}

However, when the player has advantage and loses the ball, he or she loses the advantage, so for the AdvantagePoint class the implementation looks like this:

public IPoints LoseBall()

{

    return new FortyPoints();

}

To keep things simple I decided to implicitly model deuce as both players having FortyPoints, so there’s not explicit Deuce class. Thus, AdvantagePoint returns FortyPoints when losing the ball.

Using the Visitor pattern it’s possible to keep the cyclomatic complexity at 1. The code has no branches or loops. It’s immutable to boot, so a game might look like this:

[Fact]

public void PlayerOneWinsAfterHardFight()

{

    var game = new Game()

        .PlayerOneWinsBall()

        .PlayerOneWinsBall()

        .PlayerOneWinsBall()

        .PlayerTwoWinsBall()

        .PlayerTwoWinsBall()

        .PlayerTwoWinsBall()

        .PlayerTwoWinsBall()

        .PlayerOneWinsBall()

        .PlayerOneWinsBall()

        .PlayerOneWinsBall();

    Assert.Equal(new GamePoint(), game.PlayerOneScore);

    Assert.Equal(new FortyPoints(), game.PlayerTwoScore);

}

In case you’d like to take a closer look at the code I’m attaching it to this post. It was driven completely by using the AutoFixture.Xunit extension, so if you are interested in idiomatic AutoFixture code it’s also a good example of that.

Generics in .NET are wonderful, but sometimes when doing Test-Driven Development against a generic class I’ve felt frustrated because I’ve been feeling that dropping down to the lowest common denominator and testing against, say, Foo<object> doesn’t properly capture the variability inherent in generics. On the other hand, writing the same test for five different types of T have seemed too wasteful (not to mention boring) to bother with.

That’s until it occurred to me that in xUnit.net (and possibly other unit testing frameworks) I can define a generic test class. As an example, I wanted to test-drive a class with this class definition:

public class Interval<T>

Instead of writing a set of tests against Interval<object> I rather wanted to write a set of tests against a representative set of T. This is so easy to do that I don’t know why I haven’t thought of it before. I simply declared the test class itself as a generic class:

public abstract class IntervalFacts<T>

The reason I declared the class as abstract is because that effectively prevents the test runner from trying to run the test methods directly on the class. That would fail because T is still open. However, it enabled me to write tests like this:

[Theory, AutoCatalogData]

public void MinimumIsCorrect(IComparable<T> first, 

    IComparable<T> second)

{

    var sut = new Interval<T>(first, second);

    IComparable<T> result = sut.Minimum;

    Assert.Equal(result, first);

}

In this test, I also use AutoFixture’s xUnit.net extension, but that’s completely optional. You might as well just write an old-fashioned unit test, but then you’ll need a SUT Factory that can resolve generics. If you don’t use AutoFixture any other (auto-mocking) container will do, and if you don’t use one of those, you can define a Factory Method that creates appropriate instances of T (and, in this particular case, instances of IComparable<T>).

In the above example I used a [Theory], but I might as well have been using a [Fact] as long as I had a container or a Factory Method to create the appropriate instances.

The above test doesn’t execute in itself because the owning class is abstract. I needed to declare an appropriate set of constructed types for which I wanted the test to run. To do that, I defined the following test classes:

public class DecimalIntervalFacts : IntervalFacts<decimal> { }

public class StringIntervalFacts : IntervalFacts<string> { }

public class DateTimeIntervalFacts : IntervalFacts<DateTime> { }

public class TimSpanIntervalFacts : IntervalFacts<TimeSpan> { }

The only thing these classes do is to each pick a particular type for T. However, since they are concrete classes with test methods, the test runner will pick up the test cases and execute them. This means that the single unit test I wrote above is now being executed four times – one for each constructed type.

It’s even possible to specialize the generic class and add more methods to a single specialized class. As a sanity check I wanted to write a set of tests specifically against Interval<int>, so I added this class as well:

public class Int32IntervalFacts : IntervalFacts<int>

{

    [Theory]

    [InlineData(0, 0, 0, true)]

    [InlineData(-1, 1, -1, true)]

    [InlineData(-1, 1, 0, true)]

    [InlineData(-1, 1, 1, true)]

    [InlineData(-1, 1, -2, false)]

    [InlineData(-1, 1, 2, false)]

    public void Int32ContainsReturnsCorrectResult(

        int minimum, int maximum, int value,

        bool expectedResult)

    {

        var sut = new Interval<int>(minimum, maximum);

        var result = sut.Contains(value);

        Assert.Equal(expectedResult, result);

    }

    // More tests...

}

When added as an extra class in addition to the four ‘empty’ concrete classes above, it now causes each generic method to be executed five times, whereas the above unit test is only executed for the Int32IntervalFacts class (on the other hand it’s a parameterized test, so the method is actually executed six times).

It’s also possible to write parameterized tests in the generic test class itself:

[Theory]

[InlineData(-1, -1, false)]

[InlineData(-1, 0, true)]

[InlineData(-1, 1, true)]

[InlineData(0, -1, false)]

[InlineData(0, 0, true)]

[InlineData(0, 1, true)]

[InlineData(1, -1, false)]

[InlineData(1, 0, false)]

[InlineData(1, 1, false)]

public void ContainsReturnsCorrectResult(

    int minumResult, int maximumResult,

    bool expectedResult)

{

    // Test method body

}

Since this parameterized test in itself has 9 variations and is declared by IntervalFacts<T> which now has 5 constructed implementers, this single test method will be executed 9 x 5 = 45 times!

Not that the the number of executed tests in itself is any measure of the quality of the test, but I do appreciate the ability to write generic unit tests against generic types.

Rapid feedback is one of the cornerstones of agile development. The faster we can get feedback, the less it costs to correct errors. Unit testing is one of the ways to get feedback, but not the only one. Each way we can get feedback comes with its own advantages and disadvantages.

In my experience there’s a tradeoff between the cost of setting up a feedback mechanism and the level of confidence we can get from it. This is quite intuitive to most people, but I’ve rarely seen it explicitly described. The purpose of this post is to explicitly describe and relate those different mechanisms.

Compilation

In compiled languages, compilation provides the first level of feedback. I think a lot of people don’t think about this as feedback as (for compiled languages) it’s a necessary step before the code can be executed.

The level of confidence may not be very high – we tend to laugh at statements like ‘if it compiles, it works’. However, the compiler still catches a lot of mistakes. Think about it: does your code always compile, or do you sometimes get compilation errors? Do you sometimes try to compile your code just to see if it’s possible? I certainly do, and that’s because the compiler is always available, and it’s the first and fastest level of feedback we get.

Code can be designed to take advantage of this verification step. Constructor Injection, for example, ensures that we can’t create a new instance of a class without supplying it with its required dependencies.

It’s also interesting to note that anecdotal evidence seems to suggest that unit testing is more prevalent for interpreted languages. That makes a lot of sense, because as developers we need feedback as soon as possible, and if there’s no compiler we must reach for the next level of feedback mechanism.

Static code analysis

The idea of static code analysis isn’t specific to .NET, but in certain versions of Visual Studio we have Code Analysis (which is also available as FxCop). Static code analysis is a step up from compilation – not only is code checked for syntactical correctness, but it’s also checked against a set of known anti-patterns and idioms.

Static code analysis is encapsulated expert knowledge, yet surprisingly few people use it. I think part of the reason for this is because the ratio of time against confidence isn’t as compelling as with other feedback mechanism. It takes some time to run the analysis, but like compilation the level of confidence gained from getting a clean result is not very high.

Personally, I use static code analysis once in a while (e.g. before checking in code to the default branch), but not as often as other feedback mechanisms. Still, I think this type of feedback mechanism is under-utilized.

Unit testing

Running a unit test suite is one of the most efficient ways to gain rapid feedback. The execution time is often comparable to running static code analysis while the level of confidence is much higher.

Obviously a successful unit test execution is no guarantee that the final application works as intended, but it’s a much better indicator than the two previous mechanisms. When presented with the choice of using either static code analysis or unit tests, I prefer unit tests every time because the confidence level is much higher.

If you have sufficiently high code coverage I’d say that a successful unit test suite is enough confidence to check in code and let continuous integration take care of the rest.

Keep in mind that continuous integration and other types of automated builds are feedback mechanisms. If you institute rules where people are ‘punished’ for checking in code that breaks the build, you effectively disable the automated build as a source of feedback.

Thus, the rest of these feedback mechanisms should be used rarely (if at all) on developer work stations.

Integration testing

Integration testing comes in several sub-categories. You can integrate multiple classes from within the same library, or integrate multiple libraries while still using Test Doubles instead of out-of-process resources. At this level, the cost/confidence ratio is comparable to unit testing.

Subcutaneous testing

A more full level of integration testing comes when all resources are integrated, but the tests are still driven by code instead of through the UI. While this gives a degree of confidence that is close to what you can get from a full systems test, the cost of setting up the entire testing environment is much higher. In many cases I consider this the realm of a dedicated testing department, as it’s often a full-time job to maintain the suite of automation tools that enable such tests – particularly if we are talking about distributed systems.

System testing

This is a test of the full system, often driven through the UI and supplemented with manual testing (such as exploratory testing). This provides the highest degree of confidence, but comes with a very high cost. It’s often at this level we find formal acceptance tests.

The time before we can get feedback at this level is often considerable. It may take days or even weeks or months.

Understand the cost/confidence ratio

The purpose of this post has been to talk about different ways we can get feedback when developing software. If we could get instantaneous feedback with guaranteed confidence it would be easy to choose, but as this is not the case we must understand the benefits and drawbacks of each mechanism.

It’s important to realize that there are many mechanisms, and that we can combine them in a staggered approach where we start with fast feedback (like the compiler) with a low degree of confidence and then move through successive stages that each provide a higher level of confidence.

AutoFixture is designed around the 80-20 principle. If your code is well-designed I’d expect a default instance of Fixture to be able to create specimens of your classes without too much trouble. There are cases where AutoFixture needs extra help:

• If a class consumes interfaces a default Fixture will not be able to create it. However, this is easily fixed through one of the AutoMocking Customizations.
• If an API has circular references, Fixture might enter an infinite recursion, but you can easily customize it to cut off one the references.
• Some constructors may only accept arguments that don’t fit with the default specimens created by Fixture. There are ways to deal with that as well.

I could keep on listing examples, but let’s keep it at that. The key assumption underlying AutoFixture is that these special cases are a relatively small part of the overall API you want to test – preferably much less than 20 percent.

Still, to address those special cases you’ll need to customize a Fixture instance in some way, but you also want to keep your test code DRY.

As the popularity of AutoFixture grows, I’m getting more and more glimpses of how people address this challenge: Some derive from Fixture, others create extension methods or other static methods, while others again wrap creation of Fixture instances in Factories or Builders.

There really is no need to do that. AutoFixture has an idiomatic way to encapsulate Customizations. It’s called… well… a Customization, which is just another way to say that there’s an ICustomization interface that you can implement. This concept corresponds closely to the modularization APIs for several well-known DI Containers. Castle Windsor has Installers, StructureMap has Registries and Autofac has Modules.

The ICustomization interface is simple and has a very gentle learning curve:

public interface ICustomization

{

    void Customize(IFixture fixture);

}

Anything you can do with a Fixture instance you can also do with the IFixture instance passed to the Customize method, so this is the perfect place to encapsulate common Customizations to AutoFixture. Note that the AutoMocking extensions as well as several other optional behaviors for AutoFixture are already defined as Customizations.

Using a Customization is also easy:

var fixture = new Fixture()

    .Customize(new DomainCustomization());

You just need to invoke the Customize method on the Fixture. That’s no more difficult than calling a custom Factory or extension method – particularly if you also use a Visual Studio Code Snippet.

When I start a new unit testing project, one of the first things I always do is to create a new ‘default’ customization for that project. It usually doesn’t take long before I need to tweak it a bit – if nothing else, then for adding the AutoMoqCustomization. To apply separation of concerns I encapsulate each Customization in its own class and compose them with a CompositeCustomization:

public class DomainCustomization : CompositeCustomization

{

    public DomainCustomization()

        : base(

            new AutoMoqCustomization(),

            new FuncCustomization())

    {

    }

}

Whenever I need to make sweeping changes to my Fixtures I can simply modify DomainCustomization or one of the Customizations it composes.

In fact, these days I rarely explicitly create new Fixture instances, but rather encapsulate them in a custom AutoDataAttribute like this:

public class AutoDomainDataAttribute : AutoDataAttribute

{

    public AutoDomainDataAttribute()

        : base(new Fixture()

            .Customize(new DomainCustomization()))

    {

    }

}

This means that I can reuse the DomainCustomization across normal, imperative unit tests as well as the declarative, xUnit.net-powered data theories I normally prefer:

[Theory, AutoDomainData]

public void CanReserveReturnsTrueWhenQuantityIsEqualToRemaining(

    Capacity sut, Guid id)

{

    var result = sut.CanReserve(sut.Remaining, id);

    Assert.True(result);

}

Using Customizations to encapsulate your own specializations makes it easy to compose and manage them in an object-oriented fashion.

In my previous post I described how to customize a Fixture instance to populate lists with items instead of returning empty lists. While it’s pretty easy to do so, the drawback is that you have to do it explicitly for every type you want to influence. In this post I will follow up by describing how to enable some general conventions that simply populates all collections that the Fixture resolves.

This post describes a feature that will be available in AutoFixture 2.1. It’s not available in AutoFixture 2.0, but is already available in the code repository. Thus, if you can’t wait for AutoFixture 2.1 you can download the source and built it.

Instead of having to create multiple customizations for IEnumerable<int>, IList<int>, List<int>, IEnumerable<string>, IList<string>, etc. you can simply enable these general conventions as easy as this:

var fixture = new Fixture()

    .Customize(new MultipleCustomization());

Notice that enabling conventions for populating sequences and lists with ‘many’ items is an optional customization that you must explicitly add.

This feature must be explicitly enabled. There are several reasons for that:

• It would be a breaking change if AutoFixture suddenly started to behave like this by default.
• The MultipleCustomization targets not only concrete types such as List<T> and Collection<T>, but also interfaces such as IEnumerable<T>, IList<T> etc. Thus, if you also use AutoFixture as an Auto-Mocking container, I wanted to provide the ability to define which customization takes precedence.

With that simple customization enabled, all requested IEnumerable<T> are now populated. The following will give us a finite, but populated list of integers:

var integers = 

    fixture.CreateAnonymous<IEnumerable<int>>();

This will give us a populated List<int>:

var list = fixture.CreateAnonymous<List<int>>();

This will give us a populated Collection<int>:

var collection = 

    fixture.CreateAnonymous<Collection<int>>();

As implied above, it also handles common list interfaces, so this gives us a populated IList<T>:

var list = fixture.CreateAnonymous<IList<int>>();

The exact number of ‘many’ is as always determined by the Fixture’s RepeatCount.

As this code is still (at the time of publishing) in preview, I would love to get feedback on this feature.

How do you get AutoFixture to create populated lists or sequences of items? Recently I seem to have been getting this question a lot, and luckily it’s quite easy to answer.

Let’s first look at the standard AutoFixture behavior and API.

You can ask AutoFixture to create an anonymous List like this:

var list = fixture.CreateAnonymous<List<int>>();

Seen from AutoFixture’s point of view, List<int> is just a class like any other. It has a default constructor, so AutoFixture just uses that and returns an instance. You get back an instance, no exceptions are thrown, but the list is empty. What if you’d rather want a populated list?

There are many ways to go about this. A simple, low-level solution is to populate the list after creation:

fixture.AddManyTo(list);

However, you may instead prefer getting a populated list right away. This is also possible, but before we look at how to get there, I’d like to point out a feature that surprisingly few users notice. You can create many anonymous specimens at once:

var integers = fixture.CreateMany<int>();

Armed with this knowledge, as well as the knowledge of how to map types, we can now create this customization to map IEnumerable<int> to CreateMany<int>:

fixture.Register(() => fixture.CreateMany<int>());

The Register method is really a generic method, but since we have type inference, we don’t have to write it out. However, since CreateMany<int>() returns IEnumerable<int>, this is the type we register. Thus, every time we subsequently resolve IEnumerable<int>, we will get back a populated sequence.

Getting back to the original List<int> example, we can now customize it to a populated list like this:

fixture.Register(() =>

    fixture.CreateMany<int>().ToList());

Because the ToList() extension method returns List<T>, this call registers List<int> so that we will get back a populated list of integers every time the fixture resolves List<int>.

What about other collection types that don’t have a nice LINQ extension method? Personally, I never use Collection<T>, but if you wanted, you could customize it like this:

fixture.Register(() =>

    new Collection<int>(

        fixture.CreateMany<int>().ToList()));

Since Collection<T> has a constructor overload that take IList<T> we can customize the type to use this specific overload and populate it with ‘many’ items.

Finally, we can combine all this to map from collection interfaces to populated lists. As an example, we can map from IList<int> to a populated List<int> like this:

fixture.Register<IList<int>>(() => 

    fixture.CreateMany<int>().ToList());

When we use the Register method to map types we can no longer rely on type inference. Instead, we must explicitly register IList<int> against a delegate that creates a populated List<int>. Because List<int> implements IList<int> this compiles. Whenever this fixture instance resolves IList<int> it will create a populated List<int>.

All of this describes what you can do with the strongly typed API available in AutoFixture 2.0. It’s easy and very flexible, but the only important drawback is that it’s not general. All of the customizations in this post specifically address lists and sequences of integers, but not lists of any other type. What if you would like to expand this sort of behavior to any List<T>, IEnumerable<T> etc?

Stay tuned, because in the next post I will describe how to do that.

I’ve been doing Test-Driven Development since 2003. I still do, I still love it, and I still expect to be doing it in the future. Over the years, I’ve repeatedly returned to the discussion of whether TDD should be regarded as Test-Driven Development or Test-Driven Design. For a long time I’ve been of the conviction that TDD is both of those. Not so any longer.

TDD is not a good design methodology.

Over the years I’ve written tons of code with TDD. I’ve written code where tests blindly drove the design, and I’ve written code where the design was the result of a long period of deliberation, and the tests were only the manifestations of already well-formed ideas.

I can safely say that the code where tests alone drove the design never turned out particularly well. Although it was testable and, after a fashion, ‘loosely coupled’, it was still Spaghetti Code in the sense that it lacked overall consistency and good abstractions.

On the other hand, I’m immensely pleased with code like AutoFixture 2.0, which was mostly the result of hours of careful contemplation riding my bike to and from work. It was still written test-first, but the design was well thought out in advance.

This made me think: did I just fail (repeatedly) at Test-Driven Design, or is the overall concept a fallacy?

That’s a pretty hard question to answer; what constitutes good design? In the following, let’s assume that the SOLID principles is a pretty good indicator of good design. If so, does test-first drive us towards SOLID design?

TDD versus the Single Responsibility Principle

Does TDD ensure the application of the Single Responsibility Principle (SRP)? This question is easy to answer and the answer is a resounding NO! Nothing prevents us from test-driving a God Class. I’ve seen many examples, and I’ve been guilty of it myself.

Constructor Injection is a much better help because it makes SRP violations so painful.

The score so far: 0 points to TDD.

TDD versus the Open/Closed Principle

Does TDD ensure that we follow the Open/Closed Principle (OCP)? This is a bit harder to answer. I’ve previously argued that Testability is just another name for OCP, so that would in itself imply that TDD drives OCP. However, the issue is more complex than that, because there are several different ways we can address the OCP:

• Inheritance
• Composition

According to Roy Osherove’s book The Art of Unit Testing, the Extract and Override technique is a common unit testing trick. Personally, I rarely use it, but if used it will indirectly drive us a bit towards OCP via inheritance.

However, we all know that we should favor composition over inheritance, so does TDD drive us in that direction? As I alluded to previously, TDD does tend to drive us towards the use of Test Doubles, which we can view as one way to achieve OCP via composition.

However, another favorite composition technique of mine is to add functionality with a Decorator. This is only possible if the original type implements an interface that can be decorated. It’s possible to write a test that forces a SUT to implement an interface, but TDD as a technique in itself does not drive us in that direction.

Grudgingly, however, I most admit that TDD still scores half a point against OCP, for a total score so far of ½ point.

TDD versus the Liskov Substitution Principle

Does TDD drive us towards adhering to the Liskov Substitution Princple (LSP)? Perhaps, but probably not.

Black box testing can’t protect us against the SUT attempting to downcast its dependencies, but at least it doesn’t particularly pull us in that direction either. When it comes to the SUT’s treatment of a dependency, TDD pulls in neither direction.

Can we test-drive interface implementations that inadvertently violate the LSP? Yes, easily. As I discussed in a previous post, the use of Header Interfaces pulls us towards LSP violations. The more members an interface has, the more likely are LSP violations.

TDD can definitely drive us towards Header Interfaces (although they tend to hurt in the long run). I've seen this happen numerous times, and I’ve been there myself. TDD doesn’t properly encourage LSP adherence.

The score this round: 0 points for TDD, for a running total of ½ point.

TDD versus the Interface Segregation Principle

Does TDD drive us towards the Interface Segregation Principle (ISP)? No. It’s pretty easy to test-drive a SUT towards a Header Interface, just as we can test-drive towards a God Class.

Another 0 points for TDD. The score is still ½ point to TDD.

TDD versus the Dependency Inversion Principle

Does TDD drive us towards the Dependency Inversion Principle (DIP)? Yes, it does.

The whole drive towards Testability – the ability to replace dependencies with Test Doubles – drives us exactly in the same direction as the DIP.

Since we tend to mistake such mechanistic loose coupling with proper application design, this probably explains why we, for so long, have confused TDD with good design. However, although I view loose coupling as a prerequisite for good design, it is by no means enough.

For those that still keep score, TDD scores 1 point against DIP, for a total of 1½ points.

TDD does not ensure SOLID

With 1½ out of 5 possible points I have stated my case. I am convinced that TDD itself does not drive us towards SOLID design. It’s definitely possible to use test-first techniques to drive towards SOLID designs, but that will always be an extra effort that supplements TDD; it’s not something that is inherently built into TDD.

Obviously you could argue that SOLID in itself is not the end-all, be-all of proper API design. I would agree. However, based on my experience with TDD, I think the conclusion holds. TDD does not drive us towards good design. It is not a design technique.

I still write code test-first because I find it more productive, but I make design decisions out of band. I’m a Test-Driven Design Apostate.

AutoFixture now includes a Rhino Mocks-based auto-mocking feature similar to the Moq-based auto-mocking customization previously described.

The developer of this great optional feature, the talented but discreet Mikkel has this to say:

“The auto-mocking capabilities of AutoFixture now include auto-mocking using Rhino Mocks, completely along the same lines as the existing Moq-extension. Although it will not be a part of the .zip-distribution before the next official release, it can be built from the latest source code (November 13, 2010) which contains the relevant VS2008 solution: AutoRhinoMock.sln. It is built on Rhino.Mocks version 3.6.0.0. To use it, add a reference to Ploeh.AutoFixture.AutoRhinoMock.dll and customize the Fixture instance with:

var fixture = new Fixture()

    .Customize(new AutoRhinoMockCustomization());

“which automatically will result in mocked instances of requests for interfaces and abstract classes.”

I’m really happy to see the AutoFixture eco-system grow in this way, as it both demonstrates how AutoFixture gives you great flexibility and enables you to work with the tools you prefer.

As previous posts have described, AutoFixture creates Anonymous Variables based on the notion of being able to always hit within a well-behaved Equivalence Class for a given type. This works well a lot of the time because AutoFixture has some sensible defaults: numbers are positive integers and strings are GUIDs.

This last part only works as long as strings are nothing but opaque blobs to the consuming class. This is, however, not an unreasonable assumption. Consider classes that implement Entities such as Person or Address. Strings will often take the form of FirstName, LastName, Street, etc. In all such cases, the value of the string usually doesn’t matter.

However, there will always be cases where the value of a string has a special meaning of its own. It will often be best to let AutoFixture guide us towards a better API design, but this is not always possible. Sometimes there are rules that constrain the formatting of a string.

As an example, consider a Money class with this constructor:

public Money(decimal amount, string currencyCode)
{
    if (currencyCode == null)
    {
        throw new ArgumentNullException("...");
    }
    if (!CurrencyCodes.IsValid(currencyCode))
    {
        throw new ArgumentException("...");
    }
 
    this.amount = amount;
    this.currencyCode = currencyCode;
}

Notice that the constructor only allows properly formatted currency codes (such as e.g. “DKK”, “USD”, “AUD”, etc.) through, while other strings will throw an exception. AutoFixture’s default behavior of creating GUIDs as strings is problematic, as the Money constructor will throw on a GUID.

We could attempt to fix this by changing the way AutoFixture generates strings in general, but that may not be the best solution as it may interfere with other string values. It is, however, easy to do:

fixture.Inject("DKK");

This simply injects the “DKK” string into the fixture, causing all subsequent strings to have the same value. However, a hypothetical Pizza class with Name and Description properties in addition to a Price property of type Money will now look like this:

{
  "Name": "DKK",
  "Price": {
    "Amount": 1.0,
    "CurrencyCode": "DKK"
  },
  "Description": "DKK"
}

What we really want is to customize only the currency code. This is where the extremely customizable architecture of AutoFixture can help us. As the documentation explains, lots of different request will flow through the kernel’s Chain of Responsibility to create a Money instance. To populate the two parameters of the Money constructor, two ParameterInfo requests will be issued – one for each parameter. We can take advantage of this to create a custom ISpecimenBuilder that only addresses string parameters with the name currencyCode.

public class CurrencyCodeSpecimenBuilder : 
    ISpecimenBuilder
{
    public object Create(object request,
        ISpecimenContext context)
    {
        var pi = request as ParameterInfo;
        if (pi == null)
        {
            return new NoSpecimen(request);
        }
        if (pi.ParameterType != typeof(string)
            || pi.Name != "currencyCode")
        {
            return new NoSpecimen(request);
        }
 
        return "DKK";
    }
}

It simply examines the request to determine whether this is something that it should address at all. Only if the request is a ParameterInfo representing a string parameter named currencyCode do we deal with it. In any other case we return NoSpecimen, which simply tells AutoFixture that it should ask another ISpecimenBuilder instead.

Here we just return the hard-coded string “DKK”, but we could easily have expanded the example to use a more varied generation algorithm. I will leave that, as well as how to generalize this in other ways, as exercises to the reader.

With CurrencyCodeSpecimenBuilder available, we can add it to the Fixture like this:

fixture.Customizations.Add(
    new CurrencyCodeSpecimenBuilder());

With this customization added, a Pizza instance now looks like this:

{
  "Name": "namec6b7a923-ea78-4817-9e24-a6863a597645",
  "Price": {
    "Amount": 1.0,
    "CurrencyCode": "DKK"
  },
  "Description": "Description63ef17d7-876d-46d8-af73-1ed91f83e699"
}

Notice how only the currency code is affected while all other string values are created by the default algorithm.

In a nutshell, a custom ISpecimenBuilder can be used to implement all sorts of custom conventions for AutoFixture. The one shown here applies the string “DKK” to all string parameters named currencyCode. This mean that the convention isn’t necessarily constrained to the Money constructor, but applies to all ParamterInfo instances that fit the specification.

AutoFixture 2.0 comes with a new extension for xUnit.net data theories. For those of us using xUnit.net, it can help make our unit tests more succinct and declarative.

AutoFixture’s support for xUnit.net is implemented in a separate assembly. AutoFixture itself has no dependency on xUnit.net, and if you use another unit testing framework, you can just ignore the existence of the Ploeh.AutoFixture.Xunit assembly.

Let’s go back and revisit the previous test we wrote using AutoFixture and its auto-mocking extension:

[Fact]

public void AddWillPipeMapCorrectly()

{

    // Fixture setup

    var fixture = new Fixture()

        .Customize(new AutoMoqCustomization());

    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 how all of the Fixture Setup phase is only used to create various objects that will be used in the test. First we create the fixture object, and then we use it to create four other objects. That turns out to be a pretty common idiom when using AutoFixture, so it’s worthwhile to reduce the clutter if possible.

With xUnit.net’s excellent extensibility features, we can. AutoFixture 2.0 now includes the AutoDataAttribute in a separate assembly. AutoDataAttribute derives from xUnit.net’s DataAttribute (just like InlineDataAttribute), and while we can use it as is, it becomes really powerful if we combine it with auto-mocking like this:

public class AutoMoqDataAttribute : AutoDataAttribute

{

    public AutoMoqDataAttribute()

        : base(new Fixture()

            .Customize(new AutoMoqCustomization()))

    {

    }

}

This is a custom attribute that combines AutoFixture’s two optional extensions for auto-mocking and xUnit.net support. With the AutoMoqDataAttribute in place, we can now rewrite the above test like this:

[Theory, AutoMoqData]

public void AddWillPipeMapCorrectly([Frozen]Basket basket,

    [Frozen]Mock<IPizzaMap> mapMock, PizzaPresenter pizza,

    BasketPresenter sut)

{

    // Fixture setup

    // Exercise system

    sut.Add(pizza);

    // Verify outcome

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

    // Teardown

}

The AutoDataAttribute simply uses a Fixture object to create the objects declared in the unit tests parameter list. Notice that the test is no longer a [Fact], but rather a [Theory].

The only slightly tricky thing to notice is that when we declare a parameter object, it will automatically map to a call to the CreateAnonymous method for the parameter type. However, when we need to invoke the Freeze method, we can add the [Frozen] attribute in front of the parameter.

The best part about data theories is that they don’t prevent us from writing normal unit tests in the same Test Class, and this carries over to the [AutoData] attribute. We can use it when it’s possible, but for those more complex tests where we need to interact with a Fixture instance, we can still write a normal [Fact].

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 = new Fixture()

    .Customize(new AutoMoqCustomization());

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 = new Fixture()

        .Customize(new AutoMoqCustomization());

    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 = new Fixture();

    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 = new WcfFixture();

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(this DateTime dt)

{

    var timeProviderStub = new Mock<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(this int m)

{

    return TimeSpan.FromMinutes(m);

}

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

internal static void Pass(this TimeSpan 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 previous posts 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 = new Fixture();

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

    this Fixture 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 = new Mock<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>(this Fixture fixture)

    where T : class

{

    var td = new Mock<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 = new Fixture();

    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 = new Fixture();

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

    var mapMock = new Mock<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

{

    private readonly Basket basket;

    private readonly IPizzaMap map;

    public BasketPresenter(Basket basket, IPizzaMap map)

    {

        if (basket == null)

        {

            throw new ArgumentNullException("basket");

        }

        if (map == null)

        {

            throw new ArgumentNullException("map");

        }

        this.basket = basket;

        this.map = map;

    }

    public void 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 = new Fixture();

    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 = new Fixture();

    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

{

    private readonly string name;

    public Pizza(string name)

    {

        if (name == null)

        {

            throw new ArgumentNullException("name");

        }

        this.name = name;

    }

    public string Name

    {

        get { return this.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 = new Fixture();

    fixture.Customize<ControllerContext>(ob => ob

        .OmitAutoProperties()

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

    var expectedUserName = 

        fixture.CreateAnonymous("UserName");

    var httpCtxStub = new Mock<HttpContextBase>();

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

        new GenericPrincipal(

            new GenericIdentity(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 = new Mock<HttpContextBase>();

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

    new GenericPrincipal(

        new GenericIdentity(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

{

    public ViewResult Profile()

    {

        object userName = this.User.Identity.Name;

        return this.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 = new MyClass();

    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 = new MyClass();

    // 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 = new MyClass();

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

{

    public static NotifyExpectation<T>

        ShouldNotifyOn<T, TProperty>(this T owner,

        Expression<Func<T, TProperty>> propertyPicker) 

        where T : INotifyPropertyChanged

    {

        return NotifyPropertyChanged.CreateExpectation(owner,

            propertyPicker, true);

    }

    public static NotifyExpectation<T> 

        ShouldNotNotifyOn<T, TProperty>(this T owner,

        Expression<Func<T, TProperty>> propertyPicker)

        where T : INotifyPropertyChanged

    {

        return NotifyPropertyChanged.CreateExpectation(owner,

            propertyPicker, false);

    }

    private static NotifyExpectation<T>

        CreateExpectation<T, TProperty>(T owner,

        Expression<Func<T, TProperty>> pickProperty,

        bool eventExpected) where T : INotifyPropertyChanged

    {

        string propertyName =

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

        return new NotifyExpectation<T>(owner,

            propertyName, eventExpected);

    }

}

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

public class NotifyExpectation<T>

    where T : INotifyPropertyChanged

{

    private readonly T owner;

    private readonly string propertyName;

    private readonly bool eventExpected;

    public NotifyExpectation(T owner,

        string propertyName, bool eventExpected)

    {

        this.owner = owner;

        this.propertyName = propertyName;

        this.eventExpected = eventExpected;

    }

    public void 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 AutoFixture is 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;

    }

    public int 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 = new Fixture();

    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 = new Fixture();

    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 = new RelayCommand(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 = new MainWindowViewModel(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 = new MainWindowViewModel(mockNotify);

// Exercise system

sut.ButtonCommand.Execute(new object());

// 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 = new Thing()

    {

        Number = 3,

        Text = "Anonymous text 1"

    };

    Thing thing2 = new Thing()

    {

        Number = 6,

        Text = "Anonymous text 2"

    };

    Thing thing3 = new Thing()

    {

        Number = 1,

        Text = "Anonymous text 3"

    };

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

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

    IMyInterface fake = new FakeMyInterface();

    fake.AddThing(thing1);

    fake.AddThing(thing2);

    fake.AddThing(thing3);

    MyClass sut = new MyClass(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 = new Fixture();

    IMyInterface fake = new FakeMyInterface();

    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 = new MyClassFixture();

    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 = new List<Thing>();

        this.Register<IMyInterface>(() =>

            {

                var fake = new FakeMyInterface();

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

                    fake.AddThing(t));

                return fake;

            });

    }

    internal IList<Thing> Things { get; private set; }

}

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 = new Fixture();

    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 = new Thing()

    {

        Number = 3,

        Text = "Anonymous text 1"

    };

    Thing thing2 = new Thing()

    {

        Number = 6,

        Text = "Anonymous text 2"

    };

    Thing thing3 = new Thing()

    {

        Number = 1,

        Text = "Anonymous text 3"

    };

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

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

    IMyInterface fake = new FakeMyInterface();

    fake.AddThing(thing1);

    fake.AddThing(thing2);

    fake.AddThing(thing3);

    MyClass sut = new MyClass(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 = new FakeMyInterface();

    MyClassTest.AddThingsToMyInterface(fake, things);

    MyClass sut = new MyClass(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 = new MyClassFixture();

    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 = new FakeMyInterface();

        this.Things = new List<Thing>();

    }

    internal FakeMyInterface Fake { get; private set; }

    internal IList<Thing> Things { get; private set; }

    internal void AddAnonymousThings()

    {

        int many = 3;

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

        {

            Thing t = this.CreateAnonymousThing();

            this.Things.Add(t);

            this.Fake.AddThing(t);

        }

    }

    internal MyClass CreateSut()

    {

        return new MyClass(this.Fake);

    }

    private Thing CreateAnonymousThing()

    {

        Thing t = new Thing();

        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 = new MyClass();

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

        new string(anonymousText.Reverse().ToArray());

    MyClass sut = new MyClass();

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

        new string(anonymousText.Reverse().ToArray());

    MyClass sut = new MyClass();

    // 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 = new MyClass();

    // 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 = new MyClass();

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

        new string(anonymousText.Reverse().ToArray());

    MyClass sut = new MyClass();

    // 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();

    }

    return new string(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 = new MyClass();

    // 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 = new MyClass();

    // 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 = new FakeMyInterface();

    return new MyClass(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

    new MyClass(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