As part of the Copenhagen .NET User Group (CNUG) winter and early autumn schedule, I’ll be giving a talk on (slightly advanced) TDD.

The talk will be in Danish and takes place April 15th, 2010. More details and sign-up here.

Service Locator is a well-known pattern, and since it was described by Martin Fowler, it must be good, right?

No, it’s actually an anti-pattern and should be avoided.

Let’s examine why this is so. In short, the problem with Service Locator is that it hides a class’ dependencies, causing run-time errors instead of compile-time errors, as well as making the code more difficult to maintain because it becomes unclear when you would be introducing a breaking change.

OrderProcessor example

As an example, let’s pick a hot topic in DI these days: an OrderProcessor. To process an order, the OrderProcessor must validate the order and ship it if valid. Here’s an example using a static Service Locator:

            public
            class
            OrderProcessor : IOrderProcessor

{

    publicvoid Process(Order order)

    {

        var validator
= Locator.Resolve<IOrderValidator>();

        if (validator.Validate(order))

        {

            var shipper
= Locator.Resolve<IOrderShipper>();

            shipper.Ship(order);

        }

    }

}

The Service Locator is used as a replacement for the new operator. It looks like this:

            public
            static
            class
            Locator
          

{

    privatereadonlystaticDictionary<Type, Func<object>>

        services = newDictionary<Type, Func<object>>();

    publicstaticvoid Register<T>(Func<T>
resolver)

    {

        Locator.services[typeof(T)]
= () => resolver();

    }

    publicstatic T
Resolve<T>()

    {

        return (T)Locator.services[typeof(T)]();

    }

    publicstaticvoid Reset()

    {

        Locator.services.Clear();

    }

}

We can configure the Locator using the Register method. A ‘real’ Service Locator implementation would be much more advanced than this, but this example captures the gist of it.

This is flexible and extensible, and it even supports replacing services with Test Doubles, as we will see shortly.

Given that, then what could be the problem?

API usage issues

Let’s assume for a moment that we are simply consumers of the OrderProcessor class. We didn’t write it ourselves, it was given to us in an assembly by a third party, and we have yet to look at it in Reflector.

This is what we get from IntelliSense in Visual Studio:

Okay, so the class has a default constructor. That means I can simply create a new instance of it and invoke the Process method right away:

            var order
= newOrder();

            var sut
= newOrderProcessor();

sut.Process(order);

Alas, running this code surprisingly throws a KeyNotFoundException because the IOrderValidator was never registered with Locator. This is not only surprising, it may be quite baffling if we don’t have access to the source code.

By perusing the source code (or using Reflector) or consulting the documentation (ick!) we may finally discover that we need to register an IOrderValidator instance with Locator (a completely unrelated static class) before this will work.

In a unit test test, this can be done like this:

            var validatorStub
= newMock<IOrderValidator>();

validatorStub.Setup(v => v.Validate(order)).Returns(false);

            Locator.Register(()
=> validatorStub.Object);

What is even more annoying is that because the Locator’s internal store is static, we need to invoke the Reset method after each unit test, but granted: that is mainly a unit testing issue.

All in all, however, we can’t reasonably claim that this sort of API provides a positive developer experience.

Maintenance issues

While this use of Service Locator is problematic from the consumer’s point of view, what seems easy soon becomes an issue for the maintenance developer as well.

Let’s say that we need to expand the behavior of OrderProcessor to also invoke the IOrderCollector.Collect method. This is easily done, or is it?

            public
            void Process(Order order)

{

    var validator
= Locator.Resolve<IOrderValidator>();

    if (validator.Validate(order))

    {

        var collector
= Locator.Resolve<IOrderCollector>();

        collector.Collect(order);

        var shipper
= Locator.Resolve<IOrderShipper>();

        shipper.Ship(order);

    }

}

From a pure mechanistic point of view, that was easy – we simply added a new call to Locator.Resolve and invoke IOrderCollector.Collect.

Was this a breaking change?

This can be surprisingly hard to answer. It certainly compiled fine, but broke one of my unit tests. What happens in a production application? The IOrderCollector interface may already be registered with the Service Locator because it is already in use by other components, in which case it will work without a hitch. On the other hand, this may not be the case.

The bottom line is that it becomes a lot harder to tell whether you are introducing a breaking change or not. You need to understand the entire application in which the Service Locator is being used, and the compiler is not going to help you.

Variation: Concrete Service Locator

Can we fix these issues in some way?

One variation commonly encountered is to make the Service Locator a concrete class, used like this:

            public
            void Process(Order order)

{

    var locator
= newLocator();

    var validator
= locator.Resolve<IOrderValidator>();

    if (validator.Validate(order))

    {

        var shipper
= locator.Resolve<IOrderShipper>();

        shipper.Ship(order);

    }

}

However, to be configured, it still needs a static in-memory store:

            public
            class
            Locator
          

{

    privatereadonlystaticDictionary<Type, Func<object>>

        services = newDictionary<Type, Func<object>>();

    publicstaticvoid Register<T>(Func<T>
resolver)

    {

        Locator.services[typeof(T)]
= () => resolver();

    }

    public T
Resolve<T>()

    {

        return (T)Locator.services[typeof(T)]();

    }

    publicstaticvoid Reset()

    {

        Locator.services.Clear();

    }

}

In other words: there’s no structural difference between the concrete Service Locator and the static Service Locator we already reviewed. It has the same issues and solves nothing.

Variation: Abstract Service Locator

A different variation seems more in line with true DI: the Service Locator is a concrete class implementing an interface.

            public
            interface
            IServiceLocator
          

{

    T Resolve<T>();

}

            public
            class
            Locator : IServiceLocator

{

    privatereadonlyDictionary<Type, Func<object>>
services;

    public Locator()

    {

        this.services
= newDictionary<Type, Func<object>>();

    }

    publicvoid Register<T>(Func<T>
resolver)

    {

        this.services[typeof(T)]
= () => resolver();

    }

    public T
Resolve<T>()

    {

        return (T)this.services[typeof(T)]();

    }

}

With this variation it becomes necessary to inject the Service Locator into the consumer. Constructor Injection is always a good choice for injecting dependencies, so OrderProcessor morphs into this implementation:

            public
            class
            OrderProcessor : IOrderProcessor

{

    privatereadonlyIServiceLocator locator;

    public OrderProcessor(IServiceLocator locator)

    {

        if (locator
== null)

        {

            thrownewArgumentNullException("locator");

        }

        this.locator
= locator;

    }

    publicvoid Process(Order order)

    {

        var validator
= 

            this.locator.Resolve<IOrderValidator>();

        if (validator.Validate(order))

        {

            var shipper
=

                this.locator.Resolve<IOrderShipper>();

            shipper.Ship(order);

        }

    }

}

Is this good, then?

From a developer perspective, we now get a bit of help from IntelliSense:

What does this tell us? Nothing much, really. Okay, so OrderProcessor needs a ServiceLocator – that’s a bit more information than before, but it still doesn’t tell us which services are needed. The following code compiles, but crashes with the same KeyNotFoundException as before:

            var order
= newOrder();

            var locator
= newLocator();

            var sut
= newOrderProcessor(locator);

sut.Process(order);

From the maintenance developer’s point of view, things don’t improve much either. We still get no help if we need to add a new dependency: is it a breaking change or not? Just as hard to tell as before.

Summary

The problem with using a Service Locator isn’t that you take a dependency on a particular Service Locator implementation (although that may be a problem as well), but that it’s a bona-fide anti-pattern. It will give consumers of your API a horrible developer experience, and it will make your life as a maintenance developer worse because you will need to use considerable amounts of brain power to grasp the implications of every change you make.

The compiler can offer both consumers and producers so much help when Constructor Injection is used, but none of that assistance is available for APIs that rely on Service Locator.

You can read more about DI patterns and anti-patterns in my upcoming book.

In a follow-up to his earlier post on Constructor Over-Injection, Jeffrey Palermo changes his stance on Constructor Over-Injection from anti-pattern to the more palatable code smell. In this post I introduce the concept of an Aggregate Service and outline a refactoring that addresses this code smell.

If I should extract a core message from Jeffrey Palermo’s blog post it would be that it’s a code smell if you have a class that takes too many dependencies in its constructor.

I can only agree, but only so far as it’s a code smell. However, it has nothing to do with DI in general or Constructor Injection specifically. Rather, it’s a smell that indicates a violation of the Single Responsibility Principle (SRP). Let’s review the example constructor:

            public OrderProcessor(IOrderValidator validator,

                      IOrderShipper shipper,

                      IAccountsReceivable receivable,

                      IRateExchange exchange,

                      IUserContext userContext)

In this version, I even added IOrderShipper back in as I described in my earlier post. Surely, five constructor parameters are too many.

Constructor Injection makes SRP violations glaringly obvious.

What’s not to like? My personal threshold lies somewhere around 3-4 constructor parameters, so whenever I hit three, I start to consider if I could perhaps aggregate some of the dependencies into a new type.

I call such a type an Aggregate Service. It’s closely related to Parameter Objects, but the main difference is that a Parameter Object only moves the parameters to a common root, while an Aggregate Service hides the aggregate behavior behind a new abstraction. While the Aggregate Service may start its life as a result of a pure mechanistic refactoring, it often turns out that the extracted behavior represents a Domain Concept in its own right. Congratulations: you’ve just move a little closer to adhering to the SRP!

Let’s look at Jeffrey Palermo’s OrderProcessor example. The core implementation of the class is reproduced here (recall that in my version, IOrderShipper is also an injected dependency):

            public
            SuccessResult Process(Order order)

{

    bool isValid
= _validator.Validate(order);

    if (isValid)

    {

        Collect(order);

        _shipper.Ship(order);

    }

    return CreateStatus(isValid);

}

            private
            void Collect(Order order)

{

    User user
= _userContext.GetCurrentUser();

    Price price
= order.GetPrice(_exchange, _userContext);

    _receivable.Collect(user, price);

}

If you examine the code it should quickly become apparent that the Collect method encapsulates a cluster of dependencies: IAccountsReceivable, IRateExchange and IUserContext. In this case it’s pretty obvious because they are already encapsulated in a single private method. In real production code, you may need to perform a series of internal refactorings before a pattern starts to emerge and you can extract an interface that aggregates several dependencies.

Now that we have identified the cluster of dependencies, we can extract an interface that closely resembles the Collect method:

            public
            interface
            IOrderCollector
          

{

    void Collect(Order order);

}

In lieu of a better name, I simply chose to call it IOrderCollector, but what’s interesting about extracting Aggregate Services is that over time, they often turn out to be previously implicit Domain Concepts that we have now dragged out in the open and made explicit.

We can now inject IOrderCollector into OrderProcessor and change the implementation of the private Collect method:

            private
            void Collect(Order order)

{

    _collector.Collect(order);

}

Next, we can remove the redundant dependencies, leaving us with this constructor:

            public OrderProcessor(IOrderValidator validator,

                      IOrderShipper shipper,

                      IOrderCollector collector)

With three constructor parameters it’s much more acceptable, but we can always consider repeating the procedure and extract a new Aggregate Service that aggregates IOrderShipper and IOrderCollector.

The original behavior from the Collect method is still required, but is now implemented in the OrderCollector class:

            public
            class
            OrderCollector : IOrderCollector

{

    privatereadonlyIUserContext _userContext;

    privatereadonlyIRateExchange _exchange;

    privatereadonlyIAccountsReceivable _receivable;

    public OrderCollector(IAccountsReceivable receivable,

                          IRateExchange exchange,

                          IUserContext userContext)

    {

        _receivable = receivable;

        _exchange = exchange;

        _userContext = userContext;

    }

               
#region IOrderCollector Members

    publicvoid Collect(Order order)

    {

        User user
= _userContext.GetCurrentUser();

        Price price
= 

            order.GetPrice(_exchange, _userContext);

        _receivable.Collect(user, price);

    }

               
#endregion
          

}

Here’s another class with three constructor parameters, which falls within the reasonable range. However, once again, we can begin to consider whether the interaction between IUserContext and the Order could be better modeled.

In outline form, the Introduce Aggregate Service refactoring follows these steps:

1. Analyze how dependencies interact to identify clusters of behavior.
2. Extract an interface from these clusters.
3. Copy the original implementation to a class that implements the new interface.
4. Inject the new interface into the consumer.
5. Replace the original implementation with a call the new dependency.
6. Remove the redundant dependencies.
7. Rinse and repeat :)

The beauty of Aggregate Services is that we can keep wrapping one Aggregate Service in new Aggregate Services to define more and more coarse-grained building blocks as we get closer and closer to the application boundary.

Keeping each class and its dependencies to simple interactions also makes it much easier to unit test all of them because none of them do anything particularly complex.

Adhering strictly to Constructor Injection makes it easy to see when one violates the SRP and should refactor to an Aggregate Service.

AutoFixture 1.0 is now available on the CodePlex site! Compared to Release Candidate 2 there are no changes.

The 1.0 release page has more details about this particular release, but essentially this is RC2 promoted to release status.

It's been almost a year since I started development on AutoFixture and I must say that it has been an exciting and fulfilling experience! The API has evolved, but has turned out to be surprisingly flexible, yet robust. I even had some positive surprises along the way as it dawned on me that I could do new fancy things I hadn't originally considered.

If you use the Likeness feature (of which I have yet to write), you will run into this bug in Visual Studio. The bug is only in IntelliSense, so any code using Likeness will compile and work just fine.

While this release marks the end of AutoFixture's initial days, it also marks the beginning of AutoFixture 2.0. I already have lots of plans for making it even more extensible and powerful, as well as plans for utility libraries that integrate with, say, Moq or Rhino Mocks. It's going to be an exciting new voyage!

In a reaction to Uncle Bob's recent post on Dependency Injection Inversion, Colin Decker writes that he doesn't consider the use of the single Guice @Inject annotation particularly problematic. As I read it, the central argument is that

annotations are not code. By themselves, they do nothing.

I'll have to take that at face value, but if we translate this reasoning to .NET it certainly holds true. Attributes don't do anything by themselves.

I'm not aware of any DI Container for .NET that requires us to sprinkle attributes all over our code to work (I don't consider MEF a DI Container), but for the sake of argument, let's assume that such a container exists (let's call it Needle). Would it be so bad if we had to liberally apply the Needle [Inject] attribute in large parts of our code bases?

Colin suggests no. As usual, my position is that it depends, but in most cases I would consider it bad.

If Needle is implemented like most libraries, InjectAttribute is just one of many types that make up the entire API. Other types would include NeedleContainer and its associated classes.

Java annotations may work differently, but in .NET we need to reference a library to apply one of its attributes. To apply the [Inject] attribute, we would have to reference Needle, and herein lies the problem.

Once Needle is referenced, it becomes much easier for a junior developer to accidentally start directly using other parts of the Needle API. Particularly he or she may start using Needle as a Service Locator. When that happens, Needle is no longer a passive participant of the code, but a very active one, and it becomes much harder to separate the code from the Container.

To paraphrase Uncle Bob: I don't want to write a Needle application.

We can't even protect ourselves from accidental usage by writing a convention-based unit test that fails if Needle is referenced by our code, because it must be referenced for the [Inject] attribute to be applied.

The point is that the attribute drags in a reference to the entire container, which in my opinion is a bad thing.

So when would it be less problematic?

If Needle was implemented in such a way that InjectAttribute was defined in an assembly that only contains that one type, and the rest of Needle was implemented in a different assembly, the attribute wouldn't drag the rest of the container along.

Whether this whole analysis makes sense at all in Java, and whether Guice is implemented like that, I can't say, but in most cases I would consider even a single attribute to be unacceptable pollution of my code base.

Reacting to my previous post, Krzysztof Koźmic was so kind to point out to me that I really should be using an IWindsorInstaller instead of writing the registration code in a static helper method (it did make me cringe a bit).

As it turns out, IWindsorInstaller is not a particularly well-described feature of Castle Windsor, so here's a quick introduction. Fortunately, it is very easy to understand.

The idea is simply to package configuration code in reusable modules (just like the Guice modules from Uncle Bob's post).

Refactoring the bootstrap code from my previous post, I can now move all the container configuration code into a reusable module:

While I was at it, I also changed from the fluent registration API to the generic registration methods as I didn't really need the full API, but I could have left it as it was.

BillingContainerInstaller implements IWindsorInstaller, and I can now configure my container instance like this:

The Install method takes a parameter array of IWindsorInstaller instances, so you can pass as many as you'd like.

About a week ago Uncle Bob published a post on Dependency Injection Inversion that caused quite a stir in the tiny part of the .NET community I usually pretend to hang out with. Twitter was alive with much debate, but Ayende seems to sum up the .NET DI community's sentiment pretty well:

if this is a typical example of IoC usage in the Java world, then [Uncle Bob] should peek over the fence to see how IoC is commonly implemented in the .Net space

Despite having initially left a more or less positive note to Uncle Bob's post, after having re-read it carefully, I am beginning to think the same, but instead of just telling everyone how much greener the grass is on the .NET side, let me show you.

First of all, let's translate Uncle Bob's BillingService to C#:

It's nice how easy it is to translate Java code to C#, but apart from casing and other minor deviations, let's focus on the main difference. I've added Guard Clauses to protect the injected dependencies against null values as I consider this an essential and required part of Constructor Injection – I think Uncle Bob should have added those as well, but he might have omitted them for brevity.

If you disregard the Guard Clauses, the C# version is a logical line of code shorter than the Java version because it has no DI attribute like Guice's @Inject.

Does this mean that we can't do DI with the C# version of BillingService? Uncle Bob seems to imply that we can do Dependency Inversion, but not Dependency Injection - or is it the other way around? I can't really make head or tails of that part of the post…

The interesting part is that in .NET, there's no difference! We can use DI Containers with the BillingService without sprinkling DI attributes all over our code base. The BillingService class has no reference to any DI Container.

It does, however, use the central DI pattern Constructor Injection. .NET DI Containers know all about this pattern, and with .NET's static type system they know all they need to know to wire dependencies up correctly. (I thought that Java had a static type system as well, but perhaps I am mistaken.) The .NET DI Containers will figure it out for you – you don't have to explicitly tell them how to invoke a constructor with two parameters.

We can write an entire application by using Constructor Injection and stacking dependencies without ever referencing a container!

Like the Lean concept of the Last Responsible Moment, we can wait until the application's entry point to decide how we will wire up the dependencies.

As Uncle Bob suggests, we can use Poor Man's DI and manually create the dependencies directly in Main, but as Ayende correctly observes, that only looks like an attractive alternative because the example is so simple. For complex dependency graphs, a DI Container is a much better choice.

With the C# version of BillingService, which DI Container must we select?

It doesn't matter: we can choose whichever one we would like because we have been following patterns instead of using a framework.

Here's an example of an implementation of Main using Castle Windsor:

This looks a lot like Uncle Bob's first Guice example, but instead of injecting a BillingModule into the container, we can configure it inline or in a helper method:

This corresponds more or less to the Guice-specific BillingModule, although Windsor also requires us to register the concrete BillingService as a component (this last step varies a bit from DI Container to DI Container – it is, for example, redundant in Unity).

Imagine that in the future we want to rewire this program to use a different DI Container. The only piece of code we need to change is this Composition Root. We need to change the container declaration and configuration and then we are ready to use a different DI Container.

The bottom line is that Uncle Bob's Dependency Injection Inversion is redundant in .NET. Just use a few well-known design patterns and principles and you can write entire applications with DI-friendly, DI-agnostic code bases.

I recently posted a first take on guidelines for writing DI-agnostic code. I plan to evolve these guiding principles and make them a part of my upcoming book.

AutoFixture 1.0 Release Candidate 2 is now available on the CodePlex site! Compared to Release Candidate 1 there are very few changes, but the test period uncovered the need for a few extra methods on a recent addition to the library. RC2 contains these additional methods.

This resets the clock for the Release Candidate trial period. Key users have a chance to veto this release until a week from now. If no-one complains within that period, we will promote RC2 to version 1.0.

The RC2 release page has more details about this particular release.

My previous post led to this comment by Phil Haack:

Your LazyOrderShipper directly instantiates an OrderShipper. What about the dependencies that OrderShipper might require? What if those dependencies are costly?

I didn't want to make my original example more complex than necessary to get the point across, so I admit that I made it a bit simpler than I might have liked. However, the issue is easily solved by enabling DI for the LazyOrderShipper itself.

As always, when the dependency's lifetime may be shorter than the consumer, the solution is to inject (via the constructor!) an Abstract Factory, as this modification of LazyOrderShipper shows:

            public
            class
            LazyOrderShipper2 : IOrderShipper

{

    privatereadonlyIOrderShipperFactory factory;

    privateIOrderShipper shipper;

    public LazyOrderShipper2(IOrderShipperFactory factory)

    {

        if (factory
== null)

        {

            thrownewArgumentNullException("factory");

        }

        this.factory
= factory;

    }

               
#region IOrderShipper Members

    publicvoid Ship(Order order)

    {

        if (this.shipper
== null)

        {

            this.shipper
= this.factory.Create();

        }

        this.shipper.Ship(order);

    }

               
#endregion
          

}

But, doesn't that reintroduce the OrderShipperFactory that I earlier claimed was a bad design?

No, it doesn't, because this IOrderShipperFactory doesn't rely on static configuration. The other point is that while we do have an IOrderShipperFactory, the original design of OrderProcessor is unchanged (and thus blissfully unaware of the existence of this Abstract Factory).

The lifetime of the various dependencies is completely decoupled from the components themselves, and this is as it should be with DI.

This version of LazyOrderShipper is more reusable because it doesn't rely on any particular implementation of OrderShipper – it can Lazily create any IOrderShipper.

Jeffrey Palermo recently posted a blog post titled Constructor over-injection anti-pattern – go read his post first if you want to be able to follow my arguments.

His point seems to be that Constructor Injection can be an anti-pattern if applied too much, particularly if a consumer doesn't need a particular dependency in the majority of cases.

The problem is illustrated in this little code snippet:

            bool isValid
= _validator.Validate(order);  

            if (isValid) 

{

    _shipper.Ship(order);  

}

If the Validate method returns false often, the shipper dependency is never needed.

This, he argues, can lead to inefficiencies if the dependency is costly to create. It's not a good thing to require a costly dependency if you are not going to use it in a lot of cases.

That sounds like a reasonable statement, but is it really? And is the proposed solution a good solution?

No, this isn't a reasonable statement, and the proposed solution isn't a good solution.

It would seem like there's a problem with Constructor Injection, but in reality the problem is that it is being used incorrectly and in too constrained a way.

The proposed solution is problematic because it involves tightly coupling the code to OrderShipperFactory. This is more or less a specialized application of the Service Locator anti-pattern.

Consumers of OrderProcessor have no static type information to warn them that they need to configure the OrderShipperFactory.CreationClosure static member - a completely unrelated type. This may technically work, but creates a very developer-unfriendly API. IntelliSense isn't going to be of much help here, because when you want to create an instance of OrderProcessor, it's not going to remind you that you need to statically configure OrderShipperFactory first. Enter lots of run-time exceptions.

Another issue is that he allows a concrete implementation of an interface to change the design of the OrderProcessor class - that's hardly in the spirit of the Liskov Substitution Principle. I consider this a strong design smell.

One of the commenters (Alwin) suggests instead injecting an IOrderShipperFactory. While this is a better option, it still suffers from letting a concrete implementation influence the design, but there's a better solution.

First of all we should realize that the whole case is a bit construed because although the IOrderShipper implementation may be expensive to create, there's no need to create a new instance for every OrderProcessor. Instead, we can use the so-called Singleton lifetime style where we share or reuse a single IOrderShipper instance between multiple OrderProcessor instances.

The beauty of this is that we can wait making that decision until we wire up the actual dependencies. If we have implementations of IOrderShipper that are inexpensive to create, we may still decide to create a new instance every time.

There may still be a corner case where a shared instance doesn't work for a particular implementation (perhaps because it's not thread-safe). In such cases, we can use Lazy loading to create a LazyOrderShipper like this (for clarity I've omitted making this implementation thread-safe, but that would be trivial to do):

            public
            class
            LazyOrderShipper : IOrderShipper

{

    privateOrderShipper shipper;

               
#region IOrderShipper Members

    publicvoid Ship(Order order)

    {

        if (this.shipper
== null)

        {

            this.shipper
= newOrderShipper();

        }

        this.shipper.Ship(order);

    }

               
#endregion
          

}

Notice that this implementation of IOrderShipper only creates the expensive OrderShipper instance when it needs it.

Instead of directly injecting the expensive OrderShipper instance directly into OrderProcessor, we wrap it in the LazyOrderShipper class and inject that instead. The following test proves the point:

[TestMethod]

            public
            void OrderProcessorIsFast()

{

    //
Fixture setup

    var stopwatch
= newStopwatch();

    stopwatch.Start();

    var order
= newOrder();

    var validator
= newMock<IOrderValidator>();

    validator.Setup(v => 

        v.Validate(order)).Returns(false);

    var shipper
= newLazyOrderShipper();

    var sut
= newOrderProcessor(validator.Object,

        shipper);

    //
Exercise system

    sut.Process(order);

    //
Verify outcome

    stopwatch.Stop();

    Assert.IsTrue(stopwatch.Elapsed
< 

        TimeSpan.FromMilliseconds(777));

    Console.WriteLine(stopwatch.Elapsed);

    //
Teardown

}

This test is significantly faster than 777 milliseconds because the OrderShipper never comes into play. In fact, the stopwatch instance reports that the elapsed time was around 3 ms!

The bottom line is that Constructor Injection is not an anti-pattern. On the contrary, it is the most powerful DI pattern available, and you should think twice before deviating from it.

AutoFixture 1.0 Release Candidate 1 is now available on the CodePlex site! AutoFixture is now almost ten months old and has seen extensive use internally in Safewhere during most of this time. It has proven to be very stable, expressive and generally a delight to use.

If all goes well, the Release Candidate period will be short. Key users have a chance to veto the this version, but if no-one complains within a week from now, we will promote RC1 to version 1.0.

The RC1 release page has more detail about this particular release.

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.

I'll be doing a TechTalk on the Managed Extensibility Framework and Dependency Injection at Microsoft Denmark January 20th 2010.

The talk will be in Danish. Details and sign-up here.

In my previous posts I discussed how to enable global error handling in ASP.NET MVC and how to inject a logging interface into the error handler. In these posts, I simplified things a bit to get my points across.

In production we don't use a custom ErrorHandlingControllerFactory to configure all Controllers with error handling, nor do we instantiate IExceptionFilters manually. What I described was the Poor Man's Dependency Injection (DI) approach, which I find most appropriate when describing DI concepts.

However, we really use Castle Windsor currently, so the wiring looks a bit different although it's still exactly the same thing that's going on. Neither ErrorHandlingActionInvoker nor LoggingExceptionFilter are any different than I have already described, but for completeness I wanted to share a bit of our Windsor code.

This is how we really wire our Controllers:

container.Register(AllTypes

    .FromAssemblyContaining(representativeControllerType)

    .BasedOn<Controller>()

    .ConfigureFor<Controller>(reg
=> 

        reg.LifeStyle.PerWebRequest.ServiceOverrides(

            new {
ActionInvoker = typeof(

                ErrorHandlingControllerActionInvoker)

                .FullName })));

Most of this statement simply instructs Windsor to scan all types in the specified assembly for Controller implementations and register them. The interesting part is the ServiceOverrides method call that uses Windsor's rather excentric syntax for defining that the ActionInvoker property should be wired up with an instance of the component registered as ErrorHandlingControllerActionInvoker.

Since ErrorHandlingControllerActionInvoker itself expects an IExceptionFilter instance we need to configure at least one of these as well. Instead of one, however, we have two:

container.Register(Component.For<IExceptionFilter>()

    .ImplementedBy<LoggingExceptionFilter>());

container.Register(Component.For<IExceptionFilter>()

    .ImplementedBy<HandleErrorAttribute>());

This is Windsor's elegant way of registering Decorators: you simply register the Decorator before the decorated type, and it'll Auto-Wire everything for you.

Finally, we use a ControllerFactory very similar to the WindsorControllerFactory from the MVC Contrib project.

To reiterate: You don't have to use Castle Windsor to enable global error handling or logging in ASP.NET MVC. You can code it by hand as I've demonstrated in my previous posts, or you can use some other DI Container. The purpose of this post was simply to demonstrate one way to take it to the next level.

In a previous post I described how to enable global error handling in ASP.NET MVC applications. Although I spent some time talking about the importance of DRY, another major motivation for me was to enable Dependency Injection (DI) with exception handling so that I could log stack traces before letting ASP.NET MVC handle the exception.

With the ErrorHandlingControllerActionInvoker I described, we can inject any IExceptionFilter implementation. As an example I used HandleErrorAttribute, but obviously that doesn't log anything. Once again, it would be tempting to derive from HandleErrorAttribute and override its OnException method, but staying true to the Single Responsibility Principle as well as the Open/Closed Principle I rather prefer a Decorator:

            public
            class
            LoggingExceptionFilter : IExceptionFilter

{

    privatereadonlyIExceptionFilter filter;

    privatereadonlyILogWriter logWriter;

    public LoggingExceptionFilter(IExceptionFilter filter,

        ILogWriter logWriter)

    {

        if (filter
== null)

        {

            thrownewArgumentNullException("filter");

        }

        if (logWriter
== null)

        {

            thrownewArgumentNullException("logWriter");

        }        

        this.filter
= filter;

        this.logWriter
= logWriter;

    }

               
#region IExceptionFilter Members

    publicvoid OnException(ExceptionContext filterContext)

    {

        this.logWriter.WriteError(filterContext.Exception);

        this.filter.OnException(filterContext);

    }

               
#endregion
          

}

The LoggingExceptionFilter shown above is unabridged production code. This is all it takes to bridge the gap between IExceptionFilter and some ILogWriter interface (replace with the logging framework of your choice). Notice how it simply logs the error and then passes on exception handling to the decorated IExceptionFilter.

Currently we use HandleErrorAttribute as the decorated filter so that behavior stays as expected.

c.ActionInvoker = 

    newErrorHandlingControllerActionInvoker(

        newLoggingExceptionFilter(

            newHandleErrorAttribute(),
logWriter));

This is not too different from before, except that a LoggingExceptionFilter now decorates the HandleErrorAttribute instance.

A reader asked me how AutoFixture can deal with arrays as fields on a class. More specifically, given a class like MyClassA, how can AutoFixture assign a proper array with initialized values to Items?

            public
            class
            MyClassA
          

{

    publicMyClassB[]
Items;

    publicMyClassC C;

    publicMyClassD D;

}

Ignoring the bad practice of publicly exposing fields, the main problem is that AutoFixture has no inherent understanding of arrays, so if we try to create a new instance of MyClassA by invoking the CreateAnonymous method, we would end up with Items being an array of nulls.

Obviously we want a populated array instead. There are at least a couple of ways to reach this goal.

The simplest is just to create it and modify it afterwards:

            var mc
= fixture.CreateAnonymous<MyClassA>();

mc.Items = fixture.CreateMany<MyClassB>().ToArray();

Although the CreateAnomymous method will assign an unitialized array, we immediately overwrite the value with an initialized array. The CreateMany method returns an IEnumerable<MyClassB> on which we can use the ToArray extension method to create an array.

The next option is to do almost the same thing, but as a single operation:

            var mc
= fixture.Build<MyClassA>()

    .With(x => x.Items, 

        fixture.CreateMany<MyClassB>().ToArray())

    .CreateAnonymous();

Besides the different syntax and the lower semicolon count, the biggest difference is that in this case the Items field is never assigned an unitialized array because the With method ensures that the specified value is assigned immediately.

If you get tired of writing this Builder sequence every time you want to create a new MyClassA instance, you can Customize the Fixture:

fixture.Customize<MyClassA>(ob
=>

    ob.With(x => x.Items, 

        fixture.CreateMany<MyClassB>().ToArray()));

With this customization, every time we invoke

            var mc
= fixture.CreateAnonymous<MyClassA>();

we will get an instance of MyClassA with a properly initialized Items array.

I hope you find one or more of these methods useful.

ASP.NET MVC comes with an error-handling feature that enables you to show nice error Views to your users instead of the dreaded Yellow Screen of Death. The most prominently described technique involves attributing either you Controller or a single Controller action, like we see in the AccountController created by the Visual Studio project template.

That sure is easy, but I don't like it for a number of reasons:

• Even though you can derive from HandleErrorAttribute, it's impossible to inject any dependencies into Attributes because they must be fully constructed at compile-time. That makes it really difficult to log errors to an interface.
• It violates the DRY principle. Although it can be applied at the Controller level, I still must remember to attribute all of my Controllers with the HandleErrorAttribute.

Another approach is to override Controller.OnException. That solves the DI problem, but not the DRY problem.

Attentive readers may now point out that I can define a base Controller that implements the proper error handling, and require that all my Controllers derive from this base Controller, but that doesn't satisfy me:

First of all, it still violates the DRY principle. Whether I have to remember to apply a [HandleError] attribute or derive from a : MyBaseController amounts to the same thing. I (and all my team members) have to remember this always. It's unnecessary project friction.

The second thing that bugs me about this approach is that I really do favor composition over inheritance. Error handling is a cross-cutting concern, so why should all my Controllers have to derive from a base controller to enable this? That is absurd.

Fortunately, ASP.NET MVC offers a third way.

The key lies in the Controller base class and how it deals with IExceptionFilters (which HandleErrorAttribute implements). When a Controller action is invoked, this actually happens through an IActionInvoker. The default ControllerActionInvoker is responsible for gathering the list of IExceptionFilters, so the first thing we can do is to derive from that and override its GetFilters method:

Here I'm simply injecting an IExceptionFilter instance into this class, so I'm not tightly binding it to any particular implementation – it will work with any IExceptionFilter we give it, so it simply serves the purpose of adding the filter at the right stage so that it can deal with otherwise unhandled exceptions. It's pure infrastructure code.

Notice that I first invoke base.GetFilters and then add the injected filter to the returned list of filters. This allows the normal ASP.NET MVC IExceptionFilters to attempt to deal with the error first.

This ErrorHandlingActionInvoker is only valuable if we can assign it to each and every Controller in the application. This can be done using a custom ControllerFactory:

Notice that I'm simply deriving from the DefaultControllerFactory and overriding the CreateController method to assign the ErrorHandlingActionInvoker to the created Controller.

In this example, I have chosen to inject the HandleErrorAttribute into the ErrorHandlingActionInvoker instance. This seems weird, but it's the HandleErrorAttribute that implements the default error handling logic in ASP.NET MVC, and since it implements IExceptionFilter, it works like a charm.

The only thing left to do is to wire up the custom ErrorHandlingControllerFactory in global.asax like this:

Now any Controller action that throws an exception is gracefully handled by the injected IExceptionFilter. Since the filter is added as the last in the list of ExceptionFilters, any normal [HandleError] attribute and Controller.OnException override gets a chance to deal with the exception first, so this doesn't even change behavior of existing code.

If you are trying this out on your own development machine, remember that you must modify your web.config like so:

If you run in the RemoteOnly mode, you will still see the Yellow Screen of Death on your local box.

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.

Daniel Frost has published a podcast where he discusses Dependency Injection with me. It's about half an hour long and in Danish. Hear it here.

When using Castle Windsor in web applications you would want to register many of your components with a lifestyle that is associated with a single request. This is the purpose of the PerWebRequest lifestyle.

If you try that with ASP.NET MVC on IIS7, you are likely to receive the following error message:

Looks like you forgot to register the http module Castle.MicroKernel.Lifestyle.PerWebRequestLifestyleModule
Add '<add name="PerRequestLifestyle" type="Castle.MicroKernel.Lifestyle.PerWebRequestLifestyleModule, Castle.MicroKernel" />' to the <httpModules> section on your web.config.

Unfortunately, following the instructions in the error message doesn't help. There's a discussion about this issue on the Castle Project Users forum, but the gist of it is that if you don't need to resolve components during application startup, this shouldn't be an issue, and indeed it isn't – it seems to be something else.

In my case I seem to have solved the problem by registering the HTTP module in configuration/system.webServer/modules instead of configuration/system.web/httpModules.

Although I haven't had the opportunity to dive into the technical details to understand why this works, this seems to solve the problem on both Windows Vista and Windows Server 2008.

The following feature suggestion was recently posted in the AutoFixture Issue Tracker board:

"We're using AutoFixture to create random rows of data in our DB. A lot of times though, it creates strings that are too long for the database columns. It would be nice if the .With<string> method had an overload that took in a min/max length. We want the random data, but capped at a limit.

"fixture.Build<MyObject>.With(x = x.MyString, 0, 100);

"As an aside, this is for a project that uses Nhibernate and Fluent Nhibernate, which has these lengths already defined. I would be nice if AutoFixture could automatically pick up on that somehow."

I think such an feature is an excellent idea, but I don't think I will include in AutoFixture. Why not?

So far, I have kept the AutoFixture API pretty clean and very generic, and it is my belief that this is one of the main reasons it is so expressive and flexible. There are no methods that only work on specific types (such as strings), and I am reluctant to introduce them now.

In the last six months, I have identified a lot of specialized usage idioms that I would love to package into a reusable library, but I think that they will pollute the core AutoFixture API, so I'm going to put those in one or more optional 'add-on' libraries.

The ability to define strings that are constrained on length could be one such feature, but rather than wait for a helper library, I will show you have you can implement such a method yourself.

The first thing we need is a method that can create anonymous strings given length constraints. One possible implementation is this ConstrainedStringGenerator class:

            public
            class
            ConstrainedStringGenerator
          

{

    privatereadonlyint minimumLength;

    privatereadonlyint maximumLength;

    public ConstrainedStringGenerator(int minimumLength, 

        int maximumLength)

    {

        if (maximumLength
< 0)

        {

            thrownewArgumentOutOfRangeException("...");

        }

        if (minimumLength
> maximumLength)

        {

            thrownewArgumentOutOfRangeException("...");

        }

        this.minimumLength
= minimumLength;

        this.maximumLength
= maximumLength;

    }

    publicstring CreateaAnonymous(string seed)

    {

        var s
= string.Empty;

        while (s.Length
< this.minimumLength)

        {

            s += GuidStringGenerator.CreateAnonymous(seed);

        }

        if (s.Length
> this.maximumLength)

        {

            s = s.Substring(0, this.maximumLength);

        }

        return s;

    }

}

The CreateAnonymous method uses AutoFixture's GuidStringGenerator class to create anonymous strings of the required length. For this implementation I chose a basic algorithm, but I'm sure you can create one that is more sophisticated if you need it.

Th next thing we need to do is to implement the desired With method. That can be done with an extension method works on ObjectBuilder<T>:

            public
            static
            class
            ObjectBuilderExtension
          

{

    publicstaticObjectBuilder<T>
With<T>(

        thisObjectBuilder<T>
ob,

        Expression<Func<T, string>>
propertyPicker,

        int minimumLength,

        int maximumLength)

    {

        var me
= (MemberExpression)propertyPicker.Body;

        var name
= me.Member.Name;

        var generator
=

            newConstrainedStringGenerator(

                minimumLength, maximumLength);

        var value
= generator.CreateaAnonymous(name);

        return ob.With(propertyPicker,
value);

    }

}

The method takes the same input as ObjectBuilder<T>'s With method, plus the two integers that constrain the length. Note that the propertyPicker expression has been constrained to deal only with strings.

In this implementation, we use the ConstrainedStringGenerator class to generate the desired value for the property, where after we can use the existing With method to assign the value to the property in question.

This now allows us to write Build statements like the one originally requested:

            var mc
= fixture.Build<MyClass>()

    .With(x => x.SomeText, 0, 100)

    .CreateAnonymous();

The other part of the request, regarding NHibernate integration, I will leave to the interested reader – mostly because I have never used NHibernate, so I have no clue how to do it. I would, however, love to see a blog post with that addition.

This entire example is now part of the AutoFixture test suite, so if you are interested in looking at it in more detail, you can get it from the AutoFixture source code (available at CodePlex).

AutoFixture beta 1 is now available on the CodePlex site! We have been using AutoFixture quite intensively in Safewhere for almost half a year now, and the core of it has turned out to be stable and much more powerful than I originally imagined.

During that period, I have discovered and fixed a few bugs, but the most positive experience has been how extended usage has inspired us to come up with numerous ideas to new cool features. Some of these features are already implemented in the current release, and the rest are listed on the AutoFixture site.

The beta 1 release page has more details about this particular release.

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

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

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

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

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

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

[TestMethod]

            public
            void ProfileWillReturnResultWithCorrectUserName()

{

    //
Fixture setup

    var fixture
= newFixture();

    fixture.Customize<ControllerContext>(ob
=> ob

        .OmitAutoProperties()

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

    var expectedUserName
= 

        fixture.CreateAnonymous("UserName");

    var httpCtxStub
= newMock<HttpContextBase>();

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

        newGenericPrincipal(

            newGenericIdentity(expectedUserName), null));

    fixture.Register(httpCtxStub.Object);

    var sut
= fixture.Build<MyController>()

        .OmitAutoProperties()

        .With(c => c.ControllerContext)

        .CreateAnonymous();

    //
Exercise system

    ViewResult result
= sut.Profile();

    //
Verify outcome

    var actual
= result.ViewData.Model;

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

    //
Teardown

}

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

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

Let me highlight some parts of the test.

fixture.Customize<ControllerContext>(ob
=> ob

    .OmitAutoProperties()

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

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

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

            var httpCtxStub
= newMock<HttpContextBase>();

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

    newGenericPrincipal(

        newGenericIdentity(expectedUserName), null));

fixture.Register(httpCtxStub.Object);

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

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

            var sut
= fixture.Build<MyController>()

    .OmitAutoProperties()

    .With(c => c.ControllerContext)

    .CreateAnonymous();

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

            public
            class
            MyController : Controller

{

    publicViewResult Profile()

    {

        object userName
= this.User.Identity.Name;

        returnthis.View(userName);

    }

}

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

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

Daniel Frost has published a podcast where he discusses WCF with me. It's about half an hour and in Danish. Hear it here.

For the last few months I've been writing a book for Manning tentatively titled Dependency Injection in .NET. The page about the book is now live at the Manning web site where you can read more about it and, if you would like, purchase an Early Access edition and read the chapters as they are being written.

If you have ever wanted to learn about Dependency Injection (DI) related to .NET, here's your chance!

At the moment I'm about a third of the way into the book, so there's still some way to go, but I hope to be done with it in 2010.

If you decide to purchase an Early Access edition, I'd love to receive your feedback in the online forum.

The SOLID principles of OOD as originally put forth by Robert C. Martin make for such a catchy acronym, although they seem to originally have been spelled SOLDI.

In any case I've lately been thinking a bit about these principles and it seems to me that the Single Responsibility Principle (SRP) and the Interface Segregation Principle (ISP) seem to be very much related. In essence you could say that the ISP is simply SRP applied to interfaces.

The notion underlying both is that a type should deal with only a single concept. Whether that applies to the public API or the internal implementation is less relevant because a corollary to the Liskov Substitution Principle (LSP) and Dependency Inversion Principle (DIP) is that we shouldn't really care about the internals (unless we are actually implementing, that is).

The API is what matters.

Although I do understand the subtle differences between SRP and ISP I think they are so closely related that one of them is really redundant. We can remove the ISP and still have a fairly good acronym: SOLD (although SOLID is still better).

There's one principle that I think is missing from this set: The principle about Command/Query Separation (CQS). In my opinion, this is a very important principle that should be highlighted more than is currently the case.

If we add CQS to SOLD, we are left with some less attractive acronyms:

• SCOLD
• COLDS
• CLODS

Not nearly as confidence-inspiring acronyms as SOLID, but nonetheless, I'm striving to write COLDS code.

In the previous post on AutoFixture, I demonstrated how it's possible to use a customized Builder to perform complex initialization when requesting an instance of a particular type. To recap, this was the solution I described:

            var mc
= fixture.CreateAnonymous<MyClass>();

            var mvm
= fixture.Build<MyViewModel>()

    .Do(x => x.AvailableItems.Add(mc))

    .With(x => x.SelectedItem, mc)

    .CreateAnonymous();

This code first creates an anonymous instance of MyClass that can be added to MyViewModel. It then initializes a Builder for a specific instance of MyViewModel, instructing it to

1. add the anonymous MyClass instance to the list of AvailableItems
2. assign the same instance to the SelectedItem property

While this works splendidly, it can get tiresome to write the same customization over and over again if you need to create multiple instances of the same type. It also violate the DRY principle.

When this is the case, you can alternatively register a customized Builder pipeline for the type in question (in this case MyViewModel). This is done with the Customize method:

            var mc
= fixture.CreateAnonymous<MyClass>();

fixture.Customize<MyViewModel>(ob
=> ob

    .Do(x => x.AvailableItems.Add(mc))

    .With(x => x.SelectedItem, mc));

The Customize method takes as input a function that provides an initial ObjectBuilder as input, and returns a new, customized ObjectBuilder as output. This function is registered with the type, so that each time an anonymous instance of the type is requested, the customized ObjectBuilder will be used to create the instance.

In the example, I customize the supplied ObjectBuilder (ob) in exactly the same way as before, but instead of invoking CreateAnonymous, I simply return the customized ObjectBuilder to the Fixture instance. It then saves this customized ObjectBuilder for later use.

With this customization, what before failed now succeeds:

            var mvm
= fixture.CreateAnonymous<MyViewModel>();

The Customize method is the core method for customizing AutoFixture. Most other customization methods (like Register) are simply convenience methods that wraps Customize. It is a very powerful method that can be used to define some very specific Builder algorithms for particular types.

Yesterday I released version .8.6 of AutoFixture. It is a minor release that simply adds some new features.

There are some minor breaking changes (documented on the release page), but they only affect supporting classes and don't touch on any of the code examples I have so far published. In other words, if you are using AutoFixture's fluent interface, your code should still compile.

Please go ahead and download it and use it. As always, comments and questions are welcome, either here or in the forum.

How can you make an AJAX link that updates itself in ASP.NET MVC? My colleague Mikkel and I recently had that problem and we couldn't find any guidance on this topic, so now that we have a solution, I thought I'd share it.

The problem is simple: We needed a link that invoked some server side code and updated the text of the link itself based on the result of the operation. Here is a simplified example:

Each time you click the link, it should invoke a Controller Action and return a new number that should appear as the link text.

This is pretty simple to implement once you know how. The first thing to realize is that the link and all the AJAX stuff must be placed in a user control. The only thing that needs to go into the containing page is the containing element itself:

            <
            h2
            >Self-updating
AJAX link</h2>

Click the link to update the number:

            <
            span
            id
            ="thespan">
          

    <%this.Html.RenderPartial("NumberAjaxUserControl"); %>

            </
            span
            >
          

Notice the id of the span element – this same id will be referenced from the user control.

To bootstrap this view, the Controller Action for the page contains code that assigns an initial value to the number (in this case 1):

            public
            ActionResult Index()

{

    this.ViewData["number"]
= 1.ToString();

    returnthis.View();

}

To keep the example simple, I simply add the number to the ViewData dictionary, but in any production implementation, I would opt to use a strongly typed ViewModel instead.

The NumberAjaxUserControl itself only contains the definition of the AJAX link:

            <%
            @
            Control
            Language
            ="C#"
            Inherits
            ="System.Web.Mvc.ViewUserControl"
            %>
          

            <%
            @
            Import
            Namespace
            ="System.Web.Mvc.Ajax"
            %>
          

            <%
            =
            this.Ajax.ActionLink((string)this.ViewData["number"],

    "GetNext",

    new {
number = this.ViewData["number"]
}, 

    newAjaxOptions {
UpdateTargetId = "thespan" })%>

The first parameter to the ActionLink method is simply the current number to render as the link text. Since I'm using the untyped ViewData dictionary for this example, I need to cast it to a string.

The next parameter ("GetNext") indicates the Controller Action to invoke when the link is clicked – I will cover that shortly.

The third parameter is a Route Value that specifies that the parameter number with the correct value will be supplied to the GetNext Controller Action. It uses the number stored in ViewData.

The last parameter indicates the id of the element to update. Recall from before that this name was "thespan".

The only missing piece now is the GetNext Controller Action:

            public
            PartialViewResult GetNext(int number)

{

    this.ViewData["number"]
= (number + 1).ToString();

    returnthis.PartialView("NumberAjaxUserControl");

}

In this example I simply chose to increment the number by one, but I'm sure you can imagine that this method could just as well perform a database lookup or something similar.

Notice that the method returns a PartialViewResult that uses the same user control that I used to bootstrap the thespan element. This means that every time the link is clicked, the GetNext method is updated, and the exact same user control is used to render the content that dynamically replaces the original content of the element.

It gives me great pleasure to announce that I have just release version .8.5 of AutoFixture. It is a minor release (hence the numbering) that mainly contains a lot of convenience overloads to already existing methods. There is also a single bug fix.

There are two breaking changes (documented on the release page), but they are minor and I do not expect them to cause problems. Only one of these even remotely affects any part of the API I have already discussed here, and that relates to what kind of exception is being thrown when AutoFixture is unable to create an instance of the requested type.

Please go ahead and download it and use it heavily :) As always, comments and questions are welcome.

Soon after I posted my post on the AutoFixture Custom Builder's Do method, a much better example occurred to me, so let's revisit this feature in light of a more reasonable context.

When I write WPF code, I always use the MVVM pattern. When I need to create a Master/Detail View, I usually model it so that my View Model has a list of available items, and a property that returns the currently selected item. In this way, I can bind the current Detail View to the currently selected item purely through the View Model.

Such a View Model might look like this:

            public
            class
            MyViewModel
          

{

    privatereadonlyList<MyClass>
availableItems;

    privateMyClass selectedItem;

    public MyViewModel()

    {

        this.availableItems
= newList<MyClass>();

    }

    publicICollection<MyClass>
AvailableItems

    {

        get { returnthis.availableItems;
}

    }

    publicMyClass SelectedItem

    {

        get { returnthis.selectedItem;
}

        set

        {

            if (!this.availableItems.Contains(value))

            {

                thrownewArgumentException("...");

            }

            this.selectedItem
= value;

        }

    }

}

The main point of interest is that if you attempt to set SelectedItem to an instance that's not contained in the list of available items, an exception will be thrown. That's reasonable behavior, since we want the user to select only from the available items.

By default, AutoFixture works by assigning an Anonymous Value to all writable properties. Since these values are auto-generated, the value AutoFixture is going to assign to SelectedItem will be a new instance of MyClass, and thus not one of the available items. In other words, this will throw an exception:

            var mvm
= fixture.CreateAnonymous<MyViewModel>();

There are several solutions to this situation, depending on the scenario. If you need an instance with SelectedItem correctly set to a non-null value, you can use the Do method like this:

            var mc
= fixture.CreateAnonymous<MyClass>();

            var mvm
= fixture.Build<MyViewModel>()

    .Do(x => x.AvailableItems.Add(mc))

    .With(x => x.SelectedItem, mc)

    .CreateAnonymous();

This first creates an anonymous instance of MyClass, adds it to AvailableItems as part of a customized Builder pipeline and subsequently assigns it to SelectedItem.

Another option is to skip assigning only the SelectedItem property. This is a good option if you don't need that value in a particular test. You can use the Without method to do that:

            var mvm
= fixture.Build<MyViewModel>()

    .Without(s => s.SelectedItem)

    .CreateAnonymous();

This will assign a value to all other writable properties of MyViewModel (if it had had any), except the SelectedItem property. In this case, the value of SelectedItem will be null, since it is being ignored.

Finally you can simply choose to omit all AutoProperties using the OmitAutoProperties method:

            var mvm
= fixture.Build<MyViewModel>()

    .OmitAutoProperties()

    .CreateAnonymous();

In this scenario, only MyViewModel's constructor is being executed, while all writable properties are being ignored.

As you can see, AutoFixture offers great flexibility in providing specialized custom Builders that fit almost any situation.

The default behavior of AutoFixture is to create an Anonymous Variable by assigning a value to all writable properties of the created instance. This is great in many scenarios, but not so much in others. You can disable this behavior by using the OmitAutoProperties method, but sometimes, you would like most of the writable properties set, except one or two.

Consider this simple Person class:

            public
            class
            Person
          

{

    privatePerson spouse;

    publicDateTime BirthDay
{ get; set; }

    publicstring Name
{ get; set; }

    publicPerson Spouse 

    {

        get { returnthis.spouse;
}

        set

        {

            this.spouse
= value;

            if (value != null)

            {

                value.spouse
= this;

            }

        }

    }

}

The main trouble with this class, seen from AutoFixture's perspective, is the circular reference exposed by the Spouse property. When AutoFixture attempts to create an anonymous instance of Person, it will create anonymous values for all writable properties, and that includes the Spouse property, so it attempts to create a new instance of the Person class and assign values to all public properties, including the Spouse property, etc.

In other words, this line of code throws a StackOverflowException:

            var person
= fixture.CreateAnonymous<Person>();

If you would still like to have anonymous values assigned to Name and BirthDay, you can use the Without method:

            var person
= fixture.Build<Person>()

    .Without(p => p.Spouse)

    .CreateAnonymous();

This will give you an anonymous instance of the Person class, but with the Spouse property still with its default value of null.

Several calls to Without can be chained if you want to skip more than one property.

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

You can certainly write each test manually like the following.

[TestMethod]

            public
            void ChangingMyPropertyWillRaiseNotifyEvent_Classic()

{

    //
Fixture setup

    bool eventWasRaised
= false;

    var sut
= newMyClass();

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

        {

            if (e.PropertyName
== "MyProperty")

            {

                eventWasRaised = true;

            }

        };

    //
Exercise system

    sut.MyProperty = "Some
new value";

    //
Verify outcome

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

    //
Teardown

}

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

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

[TestMethod]

            public
            void ChangingMyPropertyWillRaiseNotifyEvent_Fluent()

{

    //
Fixture setup

    var sut
= newMyClass();

    //
Exercise system and verify outcome

    sut.ShouldNotifyOn(s => s.MyProperty)

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

    //
Teardown

}

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

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

[TestMethod]

            public
            void ChangingMyPropertyWillRaiseNotifyForDerived()

{

    //
Fixture setup

    var sut
= newMyClass();

    //
Exercise system and verify outcome

    sut.ShouldNotifyOn(s => s.MyDerivedProperty)

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

    //
Teardown

}

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

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

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

            public
            static
            class
            NotifyPropertyChanged
          

{

    publicstaticNotifyExpectation<T>

        ShouldNotifyOn<T, TProperty>(this T
owner,

        Expression<Func<T,
TProperty>> propertyPicker) 

        where T
: INotifyPropertyChanged

    {

        returnNotifyPropertyChanged.CreateExpectation(owner,

            propertyPicker, true);

    }

    publicstaticNotifyExpectation<T> 

        ShouldNotNotifyOn<T, TProperty>(this T
owner,

        Expression<Func<T,
TProperty>> propertyPicker)

        where T
: INotifyPropertyChanged

    {

        returnNotifyPropertyChanged.CreateExpectation(owner,

            propertyPicker, false);

    }

    privatestaticNotifyExpectation<T>

        CreateExpectation<T, TProperty>(T owner,

        Expression<Func<T,
TProperty>> pickProperty,

        bool eventExpected) where T
: INotifyPropertyChanged

    {

        string propertyName
=

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

        returnnewNotifyExpectation<T>(owner,

            propertyName, eventExpected);

    }

}

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

            public
            class
            NotifyExpectation<T>

    where T
: INotifyPropertyChanged

{

    privatereadonly T
owner;

    privatereadonlystring propertyName;

    privatereadonlybool eventExpected;

    public NotifyExpectation(T
owner,

        string propertyName, bool eventExpected)

    {

        this.owner
= owner;

        this.propertyName
= propertyName;

        this.eventExpected
= eventExpected;

    }

    publicvoid When(Action<T>
action)

    {

        bool eventWasRaised
= false;

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

        {

            if (e.PropertyName
== this.propertyName)

            {

                eventWasRaised = true;

            }

        };

        action(this.owner);

        Assert.AreEqual<bool>(this.eventExpected,

            eventWasRaised,

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

    }

}

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

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

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

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

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

            public
            class
            Vehicle
          

{

    public Vehicle()

    {

        this.Wheels
= 4;

    }

    publicint Wheels
{ get; set; }

}

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

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

[TestMethod]

            public
            void AnonymousVehicleHasWheelsAssignedByFixture()

{

    //
Fixture setup

    var fixture
= newFixture();

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

    //
Exercise system

    var result
= sut.Wheels;

    //
Verify outcome

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

    //
Teardown

}

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

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

[TestMethod]

            public
            void VehicleWithoutAutoPropertiesWillHaveFourWheels()

{

    //
Fixture setup

    var fixture
= newFixture();

    var sut
= fixture.Build<Vehicle>()

        .OmitAutoProperties()

        .CreateAnonymous();

    //
Exercise system

    var result
= sut.Wheels;

    //
Verify outcome

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

    //
Teardown

}

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

The test using OmitAutoProperties succeeds.

The expressiveness of WPF is amazing. I particularly like the databinding and templating features. The ability to selectively render an object based on its type is very strong.

When I recently began working with ASP.NET MVC (which I like so far), I quickly ran into a scenario where I would have liked to have WPF's DataTemplates at my disposal. Maybe it's just because I've become used to WPF, but I missed the feature and set out to find out if something similar is possible in ASP.NET MVC.

Before we dive into that, I'd like to present the 'problem' in WPF terms, but the underlying View Model that I want to expose will be shared between both solutions.

The main point is that the Items property exposes a polymorphic list. While all items in this list share a common property (Name), they are otherwise different; one contains a piece of Text, one contains a Color, and one is a complex item that contains child items.

When I render this list, I want each item to render according to its type.

In WPF, this is fairly easy to accomplish with DataTemplates:

            <
            ListBox.Resources
            >
          

                
            <
            DataTemplate
             DataType
            ="{
            x
            :
            Type
             pm
            :
            NamedTextItem
            }">
          

                    
            <
            StackPanel
            >
          

                        
            <
            TextBlock
             Text
            ="{
            Binding
             Path
            =Name}"
          

                       FontWeight="bold"
/>

                        
            <
            TextBlock
             Text
            ="{
            Binding
             Path
            =Text}"
/>
          

                    
            </
            StackPanel
            >
          

                
            </
            DataTemplate
            >
          

                
            <
            DataTemplate
             DataType
            ="{
            x
            :
            Type
             pm
            :
            NamedColorItem
            }">
          

                    
            <
            StackPanel
            >
          

                        
            <
            TextBlock
             Text
            ="{
            Binding
             Path
            =Name}"
          

                       FontWeight="bold"
/>

                        
            <
            Ellipse
             Height
            ="25"
             Width
            ="25"
          

                     HorizontalAlignment="Left"

                     Fill="{Binding Path=Brush}"

                     Stroke="DarkGray"
/>

                    
            </
            StackPanel
            >
          

                
            </
            DataTemplate
            >
          

                
            <
            DataTemplate
             DataType
            ="{
            x
            :
            Type
             pm
            :
            NamedComplexItem
            }">
          

                    
            <
            StackPanel
            >
          

                        
            <
            TextBlock
             Text
            ="{
            Binding
             Path
            =Name}"
          

                       FontWeight="bold"
/>

                        
            <
            ListBox
             ItemsSource
            ="{
            Binding
             Path
            =Children}"
          

                     BorderThickness="0">

                            
            <
            ListBox.Resources
            >
          

                                
            <
            DataTemplate
          

                        DataType="{x:Type pm:ChildItem}">

                                    
            <
            TextBlock
          

                            Text="{Binding Path=Text}"
/>

                                
            </
            DataTemplate
            >
          

                            
            </
            ListBox.Resources
            >
          

                        
            </
            ListBox
            >
          

                    
            </
            StackPanel
            >
          

                
            </
            DataTemplate
            >
          

            </
            ListBox.Resources
            >
          

Each DataTemplate is contained within a ListBox. When the ListBox binds to each item in the Items list, it automatically picks the correct template for the item.

The result is something like this:

The NamedTextItem is rendered as a box containing the Name and the Text on two separate lines; the NamedColorItem is rendered as a box containing the Name and a circle filled with the Color defined by the item; and the NamedComplexItem is rendered as a box with the Name and each child of the Children list.

This is all implemented declaratively without a single line of imperative UI code.

Is it possible to do the same in ASP.NET MVC?

To my knowledge (but please correct me if I'm wrong), ASP.NET MVC has no explicit concept of a DataTemplate, so we will have to mimic it. The following describes the best I've been able to come up with so far.

In ASP.NET MVC, there's no declarative databinding, so we will need to loop through the list of items. My View page derives from ViewPage<MyViewModel>, so I can write

            <%
            foreach (var item inthis.Model.Items)

   { %>

   <divclass="ploeh">

   <%//
Render each item %>

   </div>

            <% } %>

The challenge is to figure out how to render each item according to its own template.

To define the templates, I create a UserControl for each item. The NamedTextItemUserControl derives from ViewUserControl<NamedTextItem>, which gives me a strongly typed Model:

            <
            div
            ><
            strong
            >
            <%
            =
            this.Model.Name %></strong></div>

            <
            div
            >
            <%
            =
            this.Model.Text %></div>

The other two UserControls are implemented similarly.

A UserControl can be rendered using the RenderPartial extension method, so the only thing left is to select the correct UserControl name for each item. It would be nice to be able to do this in markup, like WPF, but I'm not aware of any way that is possible.

I will have to resort to code, but we can at least strive for code that is as declarative in style as possible.

First, I need to define the map from type to UserControl:

            <%
          

    var dataTemplates
= newDictionary<Type, string>();

    dataTemplates[typeof(NamedTextItem)]
=

        "NamedTextItemUserControl";

    dataTemplates[typeof(NamedColorItem)]
=

        "NamedColorItemUserControl";

    dataTemplates[typeof(NamedComplexItem)]
=

        "NamedComplexItemUserControl";

            %>
          

Next, I can use this map to render each item correctly:

            <%
            foreach (var item inthis.Model.Items)

   { %>

   <divclass="ploeh">

   <%//
Render each item %>

   <%this.Html.RenderPartial(dataTemplates[item.GetType()],

                            item); %>

   </div>

            <% } %>

This is definitely less pretty than with WPF, but if you overlook the aesthetics and focus on the structure of the code, it's darn close to markup. The Cyclomatic Complexity of the page is only 2, and that's even because of the foreach statement that we need in any case.

The resulting page looks like this:

My HTML skills aren't good enough to draw circles with markup, so I had to replace them with blocks, but apart from that, the result is pretty much the same.

A potential improvement on this technique could be to embed the knowledge of the UserControl into each item. ASP.NET MVC Controllers already know of Views in an abstract sense, so letting the View Model know about a UserControl (identified as a string) may be conceptually sound.

The advantage would be that we could get rid of the Dictionary in the ViewPage and instead let the item itself tell us the name of the UserControl that should be used to render it.

The disadvantage would be that we lose some flexibility. It would then require a recompilation of the application if we wanted to render an item using a different UserControl.

The technique outlined here represents an explorative work in progress, so comments are welcome.

A couple of days ago I released AutoFixture .8.4. It contains a few small feature additions and a bug fix. You can get it at the AutoFixture CodePlex site as usual.

You may have noticed that I'm frequently releasing incremental versions these days. This is because we have begun using AutoFixture for writing production software at Safewhere. So far, it has been a pleasure to use AutoFixture in my daily work, and watch colleagues pick it up and run with it.

Such intensive usage obviously uncovers missing features as well as a few bugs, which is the driving force behind the frequent releases. I've been happy to observe that so far, there have been only a few bugs, and the general API is very expressive and useful.

After we ship the first product written with AutoFixture, I plan to upgrade it to version .9 (beta). That should hopefully happen in the autumn of 2009.

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.

About a year ago, one of my readers asked me about how to make custom tokens work over TPC in WCF. Here's the question again:

"i'm trying to implement the CustomToken over tcp. The original used the SymmetricSecurityBindingElement and the transport http, this works fine, but when i change URI's and and the transport, it gives an error saying:

"Binding 'CustomBinding' doesn't support creating any channel types. This often indicates that the BindingElements in a CustomBinding have been stacked incorrectly or in the wrong order. A Transport is required at the bottom of the stack. The recommended order for BindingElements is: TransactionFlow, ReliableSession, Security, CompositeDuplex, OneWay, StreamSecurity, MessageEncoding, Transport."

As it turns out, this seems to be a general issue with more transports than just TCP – at least, I've seen the exact same behavior for the Named Pipes transport.

When I originally received the question, it seemed that no-one knew the answer, and neither did I. Now, about a year later, I've managed to find a solution, and it's really simple.

If you build up your CustomBinding in code, all you need to do is set the TransferMode property to Streamed:

            var pipeTransport
= newNamedPipeTransportBindingElement();

pipeTransport.TransferMode = TransferMode.Streamed;

In this example, I'm setting the property on a Named Pipe transport, but you can do exactly the same with a TCP transport.

Although I wasn't able to find any documentation to that effect, experimentation seems to indicate that you can also set the property in a .config file (at least, it works on my computer):

            <
            namedPipeTransport
            
            
            transferMode
            ="Streamed" />

I will not claim that I fully understand this fix/workaround, or that it applies in every situation, but I hope that it might prove helpful to some of my readers some day.

It was only earlier this week that I released AutoFixture .8.2, but now I'm releasing version .8.3 – not that there was anything wrong with .8.2 (that I know of), but I had some time to implement new features, and I wanted to properly release those.

In the future I will blog about these new features (along with all the other AutoFixture features I haven't introduced yet).

Get it at the AutoFixture CodePlex site as usual.

Yesterday I created a new release (.8.2) of AutoFixture; this time with a new feature that I recently discovered that I needed, and about which I will blog later.

There are no breaking changes and no known bugs.

Previously, we saw how you can set property values while buildinganonymous variables with AutoFixture. While I insinuated that I consider this a somewhat atypical scenario, we can now safely venture forth to the truly exotic :)

Imagine that you want to build an anonymous instance of a type that requires you to call a certain method before you can start assigning properties. It's difficult to come up with a reasonable example of this, but although I consider it quite bad design, I've seen interfaces that include an Initialize method that must be called before any other member. In our example, let's call this interface IBadDesign.

Let's say that we have a class called SomeImp that implements IBadDesign. Here's the relevant part of the class:

            #region IBadDesign
Members

            public
            string Message

{

    get { returnthis.message;
}

    set

    {

        if (this.mc
== null)

        {

            thrownewInvalidOperationException("...");

        }

        this.message
= value;

        this.transformedMessage
= this.mc.DoStuff(value);

    }

}

            public
            void Initialize(MyClass mc)

{

    this.mc
= mc;

}

            #endregion
          

This is a rather ridiculous example, but I couldn't think of a better one. The main point here is that given a brand-new instance of SomeImp, this usage is invalid:

something.Message = "Ploeh";

While the above code snippet will throw an InvalidOperationException, this will work:

something.Initialize(newMyClass());

something.Message = "Ploeh";

The problem is that by default, AutoFixture ignores methods and only assigns properties, which means that this is also going to throw:

            var imp
= fixture.CreateAnonymous<SomeImp>();

As we saw with properties, we can use the Build method to customize how the type is being created. Properties can be set with the With method, while methods can be invoked with the Do method, so this is all it takes:

            var imp
= fixture.Build<SomeImp>()

    .Do(s => s.Initialize(newMyClass()))

    .CreateAnonymous();    

We don't have to explicitly set the Message property, as AutoFixture is going to do this automatically, and all implicit assignments happen after explicit actions defined by With or Do (and in case you were wondering, you can mix With and Do, and ObjectBuilder<T> will preserve the ordering).

In most cases, having to use the Do method probably constitutes a design smell of the SUT, but the method is there if you need it.

Lately, several people have implied to me that I should consider start using Twitter, so here I am, with only a vague idea about what to do with it…

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

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

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

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

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

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

            public MainWindowViewModel(Action<string>
notify)

{

    this.ButtonCommand
= newRelayCommand(p
=> 

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

}

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

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

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

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

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

            //
Fixture setup
          

            var mockNotify
= 

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

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

            var sut
= newMainWindowViewModel(mockNotify);

            //
Exercise system
          

sut.ButtonCommand.Execute(newobject());

            //
Verify outcome
          

mockNotify.VerifyAllExpectations();

            //
Teardown
          

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

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

To make it a bit easier to get started with AutoFixture without having to trawl through all my blog posts, I've added a Cheat Sheet over at the AutoFixture CodePlex site.

As I add more posts on AutoFixture, I'll update the Cheat Sheet with the essentials. Please let me know if you think something's missing.

In my previous post I described how the Build method can be used to customize how a single anonymous variable is created.

A common customization is to set a property value during creation. In most cases, this can simply be done after the anonymous variable has been created (so the following is not an AutoFixture customization):

            var mc
= fixture.CreateAnonymous<MyClass>();

mc.MyText = "Ploeh";

By default, AutoFixture assigns anonymous values to all writable properties, but since they are writable, you can always explicitly give them different values if you care.

However, there are situations when a property is writable, but can't take just any value of its type. Sometimes this is a sign that you should reconsider your API, as I've previously described, but it may also be a legitimate situation.

Consider a Filter class that has Min and Max properties. To be semantically correct, the Min property must be less than or equal to the Max property. Each property is implemented like this:

            public
            int Min

{

    get { returnthis.min;
}

    set

    {

        if (value > this.Max)

        {

            thrownewArgumentOutOfRangeException("value");

        }

        this.min
= value;

    }

}

When you ask AutoFixture to create an instance of the Filter class, it will throw an exception because it's attempting to set the Min property after the Max property, and the default algorithm for numbers is to return numbers in an increasing sequence. (In this example, the Min property is being assigned a value after the Max property, but AutoFixture has no contract that states that the order in which properties are assigned is guaranteed.) In other words, this throws an exception:

            var f
= fixture.CreateAnonymous<Filter>();

To solve this problem, we will have to customize the assignment of the Min and Max properties, before we ask AutoFixture to create an instance of the Filter class. Here's how to do that:

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

            int max
= min + 1;

            var f =
fixture.Build<Filter>()

    .With(s => s.Max, max)

    .With(s => s.Min, min)

    .CreateAnonymous();

The With method lets you specify an expression that identifies a property, as well as the value that should be assigned to that property. When you do that, AutoFixture will never attempt to assign an anonymous value to that property, but will instead use the value you specified.

In most cases, just creating a truly anonymous instance and subsequently explicitly assigning any significant values is easier, but using the Build method with one or more calls to the With method gives you the power to override any property assignments before the instance is created.

This is really nothing new, but I don't think I've explicitly stated this before: It makes a lot of sense to view delegates as anonymous one-method interfaces.

Many people liken delegates to function pointers. While that's probably correct (I wouldn't really know), it's not a very object-oriented view to take – at least not when we are dealing with managed code. To me, it makes more sense to view delegates as anonymous one-method interfaces.

Lets consider a simple example. As always, we have the ubiquitous MyClass with its DoStuff method. In this example, DoStuff takes as input an abstraction that takes a string as input and returns an integer – let's imagine that this is some kind of Strategy (notice the capital S – I'm talking about the design pattern, here).

In traditional object-oriented design, we could solve this by introducing the IMyInterface type:

            public
            interface
            IMyInterface
          

{

    int DoIt(string message);

}

The implementation of DoStuff is simply:

            public
            string DoStuff(IMyInterface strategy)

{

    return strategy.DoIt("Ploeh").ToString();

}

Hardly rocket science…

However, defining a completely new interface just to do this is not really necessary, since we could just as well have implemented DoStuff with a Func<string, int>:

            public
            string DoStuff(Func<string, int>
strategy)

{

    return strategy("Ploeh").ToString();

}

This not only frees us from defining a new interface, but also from implementing that interface to use the DoStuff method. Instead, we can simply pass a lambda expression:

            string result
= sut.DoStuff(s => s.Count());

What's most amazing is that RhinoMocks understands and treats delegates just like other abstract types, so that we can write the following to treat it as a mock:

            //
Fixture setup
          

            Func<string, int>
mock =

    MockRepository.GenerateMock<Func<string, int>>();

mock.Expect(f => f("Ploeh")).Return(42);

            var sut
= newMyClass();

            //
Exercise system
          

            string result
= sut.DoStuff(mock);

            // Verify
outcome
          

mock.VerifyAllExpectations();

            //
Teardown
          

Whenever possible, I prefer to model my APIs with delegates instead of one-method interfaces, since it gives me greater flexibility and less infrastructure code.

Obviously, this technique only works as long as you only need to abstract a single method. As soon as your abstraction needs a second method, you will need to introduce a proper interface or, preferably, an abstract base class.

Until now, I've shown you how you can make wholesale adjustments or customizations to an entire Fixture instance, effectively changing the way it creates all instances of a particular type.

In some scenarios, you'd rather want to customize how a single instance is created without influencing other instances of the same type. For this purpose, AutoFixture includes a class called ObjectBuilder<T> that can be used to do exactly that.

The easiest way to get an instance of this class is by calling Build on a Fixture instance. This will give you an instance of ObjectBuilder<T> that you can use to customize the build steps. When you are done, CreateAnonymous returns the built instance.

            var mc
= fixture.Build<MyClass>().CreateAnonymous();

This particular example doesn't define any customizations, so it's equivalent to

            var mc
= fixture.CreateAnonymous<MyClass>();

In fact, Fixture.CreateAnonymous is little more than a convenience method wrapping an ObjectBuilder (there's a few extra differences, but that's a topic for another post).

It's worth noting that the object specified by the type parameter to the Build method is first created when you call CreateAnonymous.

In future posts I'll demonstrate how to use the Build method to customize individual anonymous variables.

This post describes a particular problem I ran into when working with the Microsoft Sync Framework. Since I found a solution, I’m sharing it here to help others. If you are not having this particular problem, it’s quite safe to skip reading the rest of the post :)

While developing a SyncProvider, I wanted to create and execute a series of Integration Tests to drive my development effort. In order to do that, I wrote a simple test that simply created a SyncOrchestrator instance and invoked its Synchronize method.

Running this test gave me this error message:

“Microsoft.Synchronization.SyncException: Retrieving the COM class factory for component with CLSID {A7B3B4EE-925C-4D6C-B007-A4A6A0B09143} failed due to the following error: 80040154. --->  System.Runtime.InteropServices.COMException: Retrieving the COM class factory for component with CLSID {A7B3B4EE-925C-4D6C-B007-A4A6A0B09143} failed due to the following error: 80040154.”

It’s not often I see a COMException these days, so I was initially baffled. Since the Sync Framework also has an unmanaged API, this is really not surprising, but that didn’t help me solve my problem.

What was even weirder was that when I tried running the same code in my application, this exception was not being thrown.

It took me a couple of hours to figure out what the problem was.

Here’s a little hint: I’m running Windows Vista x64.

No: The issue is not that I’m running Vista :)

Even on x64, Visual Studio runs as a 32-bit process, and so does MSTest. Since my code was compiled to Any CPU, the application itself was running in a 64-bit process, whereas my unit test was running in a 32-bit process.

I tried changing my build output to x86, and now the application started throwing the same exception as the unit test did.

In other words: When running in a 64-bit process, everything worked as intended. When running in a 32-bit process, a COMException was thrown.

As it turned out, I had only installed the 64-bit version of the Sync Framework, and even though the SDK seems to contain builds for the other architectures as well, the COM Server wasn’t properly registered for 32-bit use.

To resolve this issue, I downloaded and installed the x86 version of the Sync Framework as well, and the problem went away.

If you are having the same problem, I hope this post helps you resolve it.

Today I've created a new release (.8.1 for lack of a better version number) of AutoFixture. While it contains some breaking changes, they all relate to features that I have yet to cover here on the blog – in other words: All the examples that I've posted so far are still valid.

Dear reader, I hope you are still with me!

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

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

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

[TestMethod]

            public
            void NumberSumIsCorrect_Naïve()

{

    //
Fixture setup

    Thing thing1
= newThing()

    {

        Number = 3,

        Text = "Anonymous
text 1"

    };

    Thing thing2
= newThing()

    {

        Number = 6,

        Text = "Anonymous
text 2"

    };

    Thing thing3
= newThing()

    {

        Number = 1,

        Text = "Anonymous
text 3"

    };

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

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

    IMyInterface fake
= newFakeMyInterface();

    fake.AddThing(thing1);

    fake.AddThing(thing2);

    fake.AddThing(thing3);

    MyClass sut
= newMyClass(fake);

    //
Exercise system

    int result
= sut.CalculateSumOfThings();

    //
Verify outcome

    Assert.AreEqual<int>(expectedSum,
result,

        "Sum
of things");

    //
Teardown

}

This test consists of 18 lines of code.

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

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

[TestMethod]

            public
            void NumberSumIsCorrect_AutoFixture()

{

    //
Fixture setup

    Fixture fixture
= newFixture();

    IMyInterface fake
= newFakeMyInterface();

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

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

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

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

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

    //
Exercise system

    int result
= sut.CalculateSumOfThings();

    //
Verify outcome

    Assert.AreEqual<int>(expectedSum,
result,

        "Sum
of things");

    //
Teardown

}

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

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

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

[TestMethod]

            public
            void NumberSumIsCorrect_DerivedFixture()

{

    //
Fixture setup

    MyClassFixture fixture
= newMyClassFixture();

    fixture.AddManyTo(fixture.Things);

    int expectedSum
= 

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

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

    //
Exercise system

    int result
= sut.CalculateSumOfThings();

    //
Verify outcome

    Assert.AreEqual<int>(expectedSum,
result,

        "Sum
of things");

    //
Teardown

}

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

            internal
            class
            MyClassFixture : Fixture

{

    internal MyClassFixture()

    {

        this.Things
= newList<Thing>();

        this.Register<IMyInterface>(()
=>

            {

                var fake
= newFakeMyInterface();

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

                    fake.AddThing(t));

                return fake;

            });

    }

    internalIList<Thing>
Things { get; privateset;
}

}

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

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

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