ploeh blog

Don’t call the container; it’ll call you

Mark Seemann — Mon, 30 Aug 2010 20:06:58 GMT

There still seems to be some confusion about what is Dependency Injection (DI) and what is a DI Container, so in this post I will try to sort it out as explicitly as possible.

DI is a set of principles and patterns that enable loose coupling.

That’s it; nothing else. Remember that old quote from p. 18 of Design Patterns?

Program to an interface; not an implementation.

This is the concern that DI addresses. The most useful DI pattern is Constructor Injection where we inject dependencies into consumers via their constructors. No container is required to do this.

The easiest way to build a DI-friendly application is to just use Constructor Injection all the way. Conversely, an application does not automatically become loosely coupled when we use a DI Container. Every time application code queries a container we have an instance of the Service Locator anti-pattern. The corollary leads to this variation of the Hollywood Principle:

Don’t call the container; it’ll call you.

A DI Container is a fantastic tool. It’s like a (motorized) mixer: you can whip cream by hand, but it’s easier with a mixer. On the other hand, without the cream the mixer is nothing. The same is true for a DI Container: to really be valuable, your code must employ Constructor Injection so that the container can auto-wire dependencies.

A well-designed application adheres to the Hollywood Principle for DI Containers: it doesn’t call the container. On the other hand, we can use the container to compose the application – or we can do it the hard way; this is called Poor Man’s DI. Here’s an example that uses Poor Man’s DI to compose a complete application graph in a console application:

private static void Main(string[]
args)

    var msgWriter
= new ConsoleMessageWriter();

    new CoalescingParserSelector(

        new IParser[]

            new HelpParser(msgWriter),

            new WineInformationParser(

                new SqlWineRepository(),

                msgWriter)

})

        .Parse(args)

        .CreateCommand()

        .Execute();

Notice how the nested structure of all the dependencies gives you an almost visual idea about the graph. What we have here is Constructor Injection all the way in.

CoalescingParserSelector’s constructor takes an IEnumerable<IParser> as input. Both HelpParser and WineInformationParser requires an IMessageWriter, and WineInformationParser also an IWineRepository. We even pull in types from different assemblies because SqlWineRepository is defined in the SQL Server-based data access assembly.

Another thing to notice is that the msgWriter variable is shared among two consumers. This is what a DI Container normally addresses with its ability to manage component lifetime. Although there’s not a DI Container in sight, we could certainly benefit from one. Let’s try to wire up the same graph using Unity (just for kicks):

private static void Main(string[]
args)

    var container
= new UnityContainer();

    container.RegisterType<IParser, WineInformationParser>("parser.info");

    container.RegisterType<IParser, HelpParser>("parser.help");

    container.RegisterType<IEnumerable<IParser>, IParser[]>();

    container.RegisterType<IParseService, CoalescingParserSelector>();

    container.RegisterType<IWineRepository, SqlWineRepository>();

    container.RegisterType<IMessageWriter, ConsoleMessageWriter>(

        new ContainerControlledLifetimeManager());

    container.Resolve<IParseService>()

        .Parse(args)

        .CreateCommand()

        .Execute();

    container.Dispose();

We are using Constructor Injection throughout, and most DI Containers (even Unity, but not MEF) natively understands that pattern. Consequently, this means that we can mostly just map interfaces to concrete types and the container will figure out the rest for us.

Notice that I’m using the Configure-Resolve-Release pattern described by Krzysztof Koźmic. First I configure the container, then I resolve the entire object graph, and lastly I dispose the container.

The main part of the application’s execution time will be spent within the Execute method, which is where all the real application code runs.

In this example I wire up a console application, but it just as well might be any other type of application. In a web application we just do a resolve per web request instead.

But wait! does that mean that we have to resolve the entire object graph of the application, even if we have dependencies that cannot be resolved at run-time? No, but that does not mean that you should pull from the container. Pull from an Abstract Factory instead.

Another question that is likely to arise is: what if I have dependencies that I rarely use? Must I wire these prematurely, even if they are expensive? No, you don’t have to do that either.

In conclusion: there is never any reason to query the container. Use a container to compose your object graph, but don’t rely on it by querying from it. Constructor Injection all the way enables most containers to auto-wire your application, and an Abstract Factory can be a dependency too.

Changing the behavior of AutoFixture auto-mocking with Moq

Mark Seemann — Wed, 25 Aug 2010 19:56:38 GMT

One of my Twitter followers who appears to be using AutoFixture recently asked me this:

So with the AutoMoqCustomization I feel like I should get Mocks with concrete types too (except the sut) - why am I wrong?

AutoFixture’s extention for auto-mocking with Moq was never meant as a general modification of behavior. Customizations extend the behavior of AutoFixture; they don’t change it. There’s a subtle difference. In any case, the auto-mocking customization was always meant as a fallback mechanism that would create Mocks for interfaces and abstract types because AutoFixture doesn’t know how to deal with those.

Apparently @ZeroBugBounce also want concrete classes to be issued as Mock instances, which is not quite the same thing; AutoFixture already has a strategy for that (it’s called ConstructorInvoker).

Nevertheless I decided to spike a little on this to see if I could get it working. It turns out I needed to open some of the auto-mocking classes a bit for extensibility (always a good thing), so the following doesn’t work with AutoFixture 2.0 beta 1, but will probably work with the RTW. Also please not that I’m reporting on a spike; I haven’t thoroughly tested all edge cases.

That said, the first thing we need to do is to remove AutoFixture’s default ConstructorInvoker that invokes the constructor of concrete classes. This is possible with this constructor overload:

public Fixture(DefaultRelays engineParts)

This takes as input a DefaultRelays instance, which is more or less just an IEnumerable<ISpecimenBuilder> (the basic building block of AutoFixture). We need to replace that with a filter that removes the ConstructorInvoker. Here’s a derived class that does that:

public class FilteringRelays : DefaultEngineParts

    private readonly Func<ISpecimenBuilder, bool>
spec;

    public FilteringRelays(Func<ISpecimenBuilder, bool>
specification)

        if (specification
== null)

            throw new ArgumentNullException("specification");

        this.spec
= specification;

    public override IEnumerator<ISpecimenBuilder>
GetEnumerator()

        var enumerator
= base.GetEnumerator();

        while (enumerator.MoveNext())

            if (this.spec(enumerator.Current))

                yield return enumerator.Current;

DefaultEngineParts already derive from DefaultRelays, so this enables us to use the overloaded constructor to remove the ConstructorInvoker by using these filtered relays:

Func<ISpecimenBuilder, bool>
concreteFilter

    = sb => !(sb is ConstructorInvoker);

var relays
= new FilteringRelays(concreteFilter);

The second thing we need to do is to tell the AutoMoqCustomization that it should Mock all types, not just interfaces and abstract classes. With the new (not in beta 1) overload of the constructor, we can now supply a Specification that determines which types should be mocked.:

Func<Type, bool>
mockSpec = t => true;

We can now create the Fixture like this to get auto-mocking of all types:

var fixture
= new Fixture(relays).Customize(

    new AutoMoqCustomization(new MockRelay(mockSpec)));

With this Fixture instance, we can now create concrete classes that are mocked. Here’s the full test that proves it:

[Fact]

public void CreateAnonymousMockOfConcreteType()

    //
Fixture setup

    Func<ISpecimenBuilder, bool>
concreteFilter

        = sb => !(sb is ConstructorInvoker);

    var relays
= new FilteringRelays(concreteFilter);

    Func<Type, bool>
mockSpec = t => true;

    var fixture
= new Fixture(relays).Customize(

        new AutoMoqCustomization(new MockRelay(mockSpec)));

    //
Exercise system

    var foo
= fixture.CreateAnonymous<Foo>();

    foo.DoIt();

    //
Verify outcome

    var fooTD
= Mock.Get(foo);

    fooTD.Verify(f => f.DoIt());

    //
Teardown

Foo is this concrete class:

public class Foo

    public virtual void DoIt()

Finally, a word of caution: this is a spike. It’s not fully tested and is bound to fail in certain cases: at least one case is when the type to be created is sealed. Since Moq can’t create a Mock of a sealed type, the above code will fail in that case. However, we can address this issue with some more sophisticated filters and Specifications. However, I will leave that up to the interested reader (or a later blog post).

All in all I think this provides an excellent glimpse of the degree of extensibility that is built into AutoFixture 2.0’s kernel.

AutoFixture as an auto-mocking container

Mark Seemann — Thu, 19 Aug 2010 19:25:50 GMT

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

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

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

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

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

var fixture
= new Fixture()

    .Customize(new AutoMoqCustomization());

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

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

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

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

[Fact]

public void AddWillPipeMapCorrectly()

    //
Fixture setup

    var fixture
= new Fixture()

        .Customize(new AutoMoqCustomization());

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

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

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

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

    //
Exercise system

    sut.Add(pizza);

    //
Verify outcome

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

    //
Teardown

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

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

AutoFixture 2.0 beta 1

Mark Seemann — Mon, 09 Aug 2010 11:32:06 GMT

It gives me great pleasure to announce that AutoFixture 2.0 beta 1 is now available for download. Compared to version 1.1 AutoFixture 2.0 is implemented using a new and much more open and extensible engine that enables many interesting scenarios.

Despite the new engine and the vastly increased potential, the focus on version 2.0 has been to ensure that the current, known feature set was preserved.

What’s new?

While AutoFixture 2.0 introduces new features, this release is first and foremost an upgrade to a completely new internal architecture, so the number of new releases is limited. Never the less, the following new features are available in version 2.0:

Support for enums
Full support of arrays
Optional tracing
Improved extensibility
Optional auto-mocking with Moq (implemented as a separate, optional assembly)
Optional extensions for xUnit.net (implemented as a separate, optional assembly)

There are still open feature requests for AutoFixture, so now that the new engine is in place I can again focus on implementing some of the features that were too difficult to address with the old engine.

Breaking changes

Version 2.0 introduces some breaking changes, although the fundamental API remains recognizable.

A lot of the original methods on Fixture are now extension methods on IFixture (a new interface). The methods include CreateAnonymous<T>, CreateMany<T> and many others, so you will need to include a using directive for Ploeh.AutoFixture to compile the unit test code.
CreateMany<T> still returns IEnumerable<T>, but the return value is much more consistently deferred. This means that in almost all cases you should instantly stabilize the sequence by converting it to a List<T>, an array or similar.
Several methods are now deprecated in favor of new methods with better names.

A few methods were also removed, but only those that were already deprecated in version 1.1.

Roadmap

The general availability of beta 1 of AutoFixture 2.0 marks the beginning of a trial period. If no new issues are reported within the next few weeks, a final version 2.0 will be released. If too many issues are reported, a new beta version may be necessary.

Please report any issues you find.

After the release of the final version 2.0 my plan is currently to focus on the Idioms project, although there are many other new features that might warrant my attention.

Blog posts about the new features will also follow soon.

StructureMap PerRequest vs. Unique lifetimes

Mark Seemann — Tue, 20 Jul 2010 20:42:53 GMT

StructureMap offers several different lifetimes, among these two known as PerRequest and Unique respectively. Recently I found myself wondering what was the difference between those two, but a little help from Jeremy Miller put me on the right track.

In short, Unique is equivalent to what Castle Windsor calls Transient: every time an instance of a type is needed, a new instance is created. Even if we need the same service multiple times in the same resolved graph, multiple instances are created.

PerRequest, on the other hand, is a bit special. Each type can be viewed as a Singleton within a single call to GetInstance, but as Transient across different invocations of GetInstance. In other words, the same instance will be shared within a resolved object graph, but if we resolve the same root type once more, we will get a new shared instance – a Singleton local to that graph.

Here are some unit tests I wrote to verify this behavior (recall that PerRequest is StructureMap’s default lifestyle):

[Fact]

public void ResolveServicesWithSameUniqueDependency()

    var container
= new Container();

    container.Configure(x =>

        var unique
= new UniquePerRequestLifecycle();

        x.For<IIngredient>().LifecycleIs(unique)

            .Use<Shrimp>();

        x.For<OliveOil>().LifecycleIs(unique);

        x.For<EggYolk>().LifecycleIs(unique);

        x.For<Vinegar>().LifecycleIs(unique);

        x.For<IIngredient>().LifecycleIs(unique)

            .Use<Vinaigrette>();

        x.For<IIngredient>().LifecycleIs(unique)

            .Use<Mayonnaise>();

        x.For<Course>().LifecycleIs(unique);

});

    var c1
= container.GetInstance<Course>();

    var c2
= container.GetInstance<Course>();

    Assert.NotSame(

        c1.Ingredients.OfType<Vinaigrette>().Single().Oil,

        c1.Ingredients.OfType<Mayonnaise>().Single().Oil);

    Assert.NotSame(

        c2.Ingredients.OfType<Vinaigrette>().Single().Oil,

        c2.Ingredients.OfType<Mayonnaise>().Single().Oil);

    Assert.NotSame(

        c1.Ingredients.OfType<Vinaigrette>().Single().Oil,

        c2.Ingredients.OfType<Vinaigrette>().Single().Oil);

[Fact]

public void ResolveServicesWithSamePerRequestDependency()

    var container
= new Container();

    container.Configure(x =>

        x.For<IIngredient>().Use<Shrimp>();

        x.For<OliveOil>();

        x.For<EggYolk>();

        x.For<Vinegar>();

        x.For<IIngredient>().Use<Vinaigrette>();

        x.For<IIngredient>().Use<Mayonnaise>();

});

    var c1
= container.GetInstance<Course>();

    var c2
= container.GetInstance<Course>();

    Assert.Same(

        c1.Ingredients.OfType<Vinaigrette>().Single().Oil,

        c1.Ingredients.OfType<Mayonnaise>().Single().Oil);

    Assert.Same(

        c2.Ingredients.OfType<Vinaigrette>().Single().Oil,

        c2.Ingredients.OfType<Mayonnaise>().Single().Oil);

    Assert.NotSame(

        c1.Ingredients.OfType<Vinaigrette>().Single().Oil,

        c2.Ingredients.OfType<Vinaigrette>().Single().Oil);

Notice that in both cases, the OliveOil instances are different across two independently resolved graphs (c1 and c2).

However, within each graph, the same OliveOil instance is shared in the PerRequest configuration, whereas they are different in the Unique configuration.

Domain Objects and IDataErrorInfo

Mark Seemann — Mon, 12 Jul 2010 12:58:16 GMT

Occasionally I get a question about whether it is reasonable or advisable to let domain objects implement IDataErrorInfo. In summary, my answer is that it’s not so much a question about whether it’s a leaky abstraction or not, but rather whether it makes sense at all. To me, it doesn’t.

Let us first consider the essence of the concept underlying IDataErrorInfo: It provides information about the validity of an object. More specifically, it provides error information when an object is in an invalid state.

This is really the crux of the matter. Domain Objects should be designed so that they cannot be put into invalid states. They should guarantee their invariants.

Let us return to the good old DanishPhoneNumber example. Instead of accepting or representing a Danish phone number as a string or integer, we model it as a Value Object that encapsulates the appropriate domain logic.

More specifically, the class’ constructor guarantees that you can’t create an invalid instance:

private readonly int number;

public DanishPhoneNumber(int number)

    if ((number
< 112) ||

        (number > 99999999))

        throw new ArgumentOutOfRangeException("number");

    this.number
= number;

Notice that the Guard Clause guarantees that you can’t create an instance with an invalid number, and the readonly keyword guarantees that you can’t change the value afterwards. Immutable types make it easier to protect a type’s invariants, but it is also possible with mutable types – you just need to place proper Guards in public setters and other mutators, as well as in the constructor.

In any case, whenever a Domain Object guarantees its invariants according to the correct domain logic it makes no sense for it to implement IDataErrorInfo; if it did, the implementation would be trivial, because there would never be an error to report.

Does this mean that IDataErrorInfo is a redundant interface? Not at all, but it is important to realize that it’s an Application Boundary concern instead of a Domain concern. At Application Boundaries, data entry errors will happen, and we must be able to cope with them appropriately; we don’t want the application to crash by passing unvalidated data to DanishPhoneNumber’s constructor.

Does this mean that we should duplicate domain logic at the Application Boundary? That should not be necessary. At first, we can apply a simple refactoring to the DanishPhoneNumber constructor:

public DanishPhoneNumber(int number)

    if (!DanishPhoneNumber.IsValid(number))

        throw new ArgumentOutOfRangeException("number");

    this.number
= number;

public static bool IsValid(int number)

    return (112
<= number)

        && (number <= 99999999);

We now have a public IsValid method we can use to implement an IDataErrorInfo at the Application Boundary. Next steps might be to add a TryParse method.

IDataErrorInfo implementations are often related to input forms in user interfaces. Instead of crashing the application or closing the form, we want to provide appropriate error messages to the user. We can use the Domain Object to provide validation logic, but the concern is completely different: we want the form to stay open until valid data has been entered. Not until all data is valid do we allow the creation of a Domain Object from that data.

In short, if you feel tempted to add IDataErrorInfo to a Domain Class, consider whether you aren’t about to violate the Single Responsibility Principle. In my opinion, this is the case, and you would be better off reconsidering the design.

Introducing AutoFixture Likeness

Mark Seemann — Tue, 29 Jun 2010 06:39:30 GMT

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

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

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

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

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

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

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

[TestMethod]

public void AddWillAddToBasket_Likeness()

    //
Fixture setup

    var fixture
= new Fixture();

    fixture.Register<IPizzaMap, PizzaMap>();

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

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

    var expectedPizza
=

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

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

    //
Exercise system

    sut.Add(pizza);

    //
Verify outcome

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

    //
Teardown

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

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

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

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

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

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

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

using Ploeh.SemanticComparison.Fluent;

Upcoming talks spring 2010

Mark Seemann — Sun, 23 May 2010 16:11:37 GMT

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

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

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

Sneak view at Castle’s WCF Facility

Mark Seemann — Tue, 18 May 2010 05:27:56 GMT

One of Castle Windsor’s facilities addresses wiring up of WCF services. So far, the sparse documentation for the WCF Facility seems to indicate that you have to configure your container in a global.asax. That’s not much to my liking. First of all, it reeks of ASP.NET, and secondly, it’s not going to work if you expose WCF over protocols other than HTTP.

However, now that we know that a custom ServiceHostFactory is effectively a Singleton, a much better alternative is to derive from the WCF Facility’s DefaultServiceHost class:

public class FooServiceHostFactory :

    DefaultServiceHostFactory

    public FooServiceHostFactory()

        : base(FooServiceHostFactory.CreateKernel())

    private static IKernel CreateKernel()

        var container
= new WindsorContainer();

        container.AddFacility<WcfFacility>();

        container.Register(Component

            .For<FooService>()

            .LifeStyle.Transient);

        container.Register(Component

            .For<IBar>()

            .ImplementedBy<Bar>());

        return container.Kernel;

Although it feels a little odd to create a container and then not really use it, but only its Kernel property, this works like a charm. It correctly wires up this FooService:

public class FooService : IFooService

    private readonly IBar bar;

    public FooService(IBar bar)

        if (bar
== null)

            throw new ArgumentNullException("bar");

        this.bar
= bar;

   
#region IFooService Members

    public string Foo()

        return this.bar.Baz;

   
#endregion

However, instead of the static CreateKernel method that creates the IKernel instance, I suggest that the WCF Facility utilizes the Factory Method pattern. As the WCF Facility has not yet been released, perhaps there’s still time for that change.

In any case, the WCF Facility saves you from writing a lot of infrastructure code if you would like to wire your WCF services with Castle Windsor.

ServiceHostFactory lifetime

Mark Seemann — Mon, 17 May 2010 05:42:33 GMT

For a while I’ve been wondering about the lifetime behavior of custom ServiceHostFactory classes hosted in IIS. Does IIS create an instance per request? Or a single instance to handle all requests?

I decided to find out, so I wrote a little test service. The conclusion seems to be that there is only a single instance that servers as a factory for all requests. This is very fortunate, since it gives us an excellent place to host a DI Container. The container can then manage the lifetime of all components, including Singletons that will live for the duration of the process.

If you are curious how I arrived at this conclusion, here’s the code I wrote. I started out with this custom ServiceHostFactory:

public class PocServiceHostFactory : ServiceHostFactory

    private static int number
= 1;

    public PocServiceHostFactory()

        Interlocked.Increment(

            ref PocServiceHostFactory.number);

    protected override ServiceHost CreateServiceHost(

        Type serviceType, Uri[]
baseAddresses)

        return new PocServiceHost(

            PocServiceHostFactory.number,
serviceType,

            baseAddresses);

The idea is that every time a new instance of ServiceHostFactory is created, the static number is incremented.

The PocServiceHostFactory just forwards the number to the PocServiceHost:

public class PocServiceHost : ServiceHost

    public PocServiceHost(int number, Type serviceType,

        Uri[]
baseAddresses)

        : base(serviceType,
baseAddresses)

        foreach (var cd in

            this.ImplementedContracts.Values)

            cd.Behaviors.Add(

                new NumberServiceInstanceProvider(

                    number));

The PocServiceHost just forwards the number to the NumberServiceInstanceProvider:

public class NumberServiceInstanceProvider :

    IInstanceProvider, IContractBehavior

    private readonly int number;

    public NumberServiceInstanceProvider(int number)

        this.number
= number;

   
#region IInstanceProvider Members

    public object GetInstance(

        InstanceContext instanceContext,

        Message message)

        return this.GetInstance(instanceContext);

    public object GetInstance(

        InstanceContext instanceContext)

        return new NumberService(this.number);

    public void ReleaseInstance(

        InstanceContext instanceContext,

        object instance)

   
#endregion

   
#region IContractBehavior Members

    public void AddBindingParameters(

        ContractDescription contractDescription,

        ServiceEndpoint endpoint,

        BindingParameterCollection bindingParameters)

    public void ApplyClientBehavior(

        ContractDescription contractDescription,

        ServiceEndpoint endpoint,

        ClientRuntime clientRuntime)

    public void ApplyDispatchBehavior(

        ContractDescription contractDescription,

        ServiceEndpoint endpoint,

        DispatchRuntime dispatchRuntime)

        dispatchRuntime.InstanceProvider = this;

    public void Validate(

        ContractDescription contractDescription,

        ServiceEndpoint endpoint)

   
#endregion

The relevant part of NumberServiceInstanceProvider is the GetInstanceMethod that simply forwards the number to the NumberService:

public class NumberService : INumberService

    private readonly int number;

    public NumberService(int number)

        this.number
= number;

   
#region INumberService Members

    public int GetNumber()

        return this.number;

   
#endregion

As you can see, NumberService simply returns the injected number.

The experiment is now to host NumberService in IIS using PocServiceHostFactory. If there is only one ServiceHostFactory per application process, we would expect that the same number (2) is returned every time we invoke the GetNumber operation. If, on the other hand, a new instance of ServiceHostFactory is created per request, we would expect the number to increase for every request.

To test this I spun up a few instances of WcfTestClient.exe and invoked the operation. It consistently returns 2 across multiple clients and multiple requests. This supports the hypothesis that there is only one ServiceHostFactory per service process.

Fun with literal extensions and Ambient Context

Mark Seemann — Tue, 27 Apr 2010 04:24:25 GMT

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

this.closedAt
= TimeProvider.Current.UtcNow;

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

//
Fixture setup

var fixture
= new WcfFixture();

DateTime.Now.Freeze();

fixture.Register(1.Minutes());

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

sut.PutInOpenState();

2.Minutes().Pass();

//
Exercise system

sut.Guard();

//
Verify outcome

Assert.IsInstanceOfType(sut.State,

    typeof(HalfOpenCircuitState));

//
Teardown

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

DateTime.Now.Freeze();

With the TimeProvider and an extension method, we can:

internal static void Freeze(this DateTime dt)

    var timeProviderStub
= new Mock<TimeProvider>();

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

    TimeProvider.Current
= timeProviderStub.Object;

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

Later in the test I state that 2 minutes pass:

2.Minutes().Pass();

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

First, the literal extension:

internal static TimeSpan Minutes(this int m)

    return TimeSpan.FromMinutes(m);

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

internal static void Pass(this TimeSpan ts)

    var previousTime
= TimeProvider.Current.UtcNow;

    (previousTime + ts).Freeze();

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

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

Changing Windsor lifestyles after the fact

Mark Seemann — Mon, 26 Apr 2010 05:09:42 GMT

I recently had the need to change the lifestyles of all components in a WindsorContainer (read on to the end if you want to know why). This turned out to be amazingly simple to do.

The problem was this: I had numerous components registered in a WindsorContainer, some of them as Singletons, some as Transients and yet again some as PerWebRequest. Configuration was even defined in numerous IWindsorInstallers, including some distributed XML files. I now needed to spin up a second container with the same configuration as the first one, except that the lifestyles should be all Singletons across the board.

This can be easily accomplished by implementing a custom IContributeComponentModelConstruction type. Here’s a simple example:

Consider this IWindsorInstaller:

public class FooInstaller : IWindsorInstaller

   
#region IWindsorInstaller Members

    public void Install(IWindsorContainer container,

        IConfigurationStore store)

        container.Register(Component

            .For<IFoo>()

            .ImplementedBy<Foo>()

            .LifeStyle.Transient);

   
#endregion

The important point to notice is that it registers the lifestyle as Transient. In other words, this container will always return new Foo instances:

var container
= new WindsorContainer();

container.Install(new FooInstaller());

We can override this behavior by adding this custom IContributeComponentModelConstruction:

public class SingletonEqualizer :

    IContributeComponentModelConstruction

    public void ProcessModel(IKernel kernel,

        ComponentModel model)

        model.LifestyleType = LifestyleType.Singleton;

In this very simple example, I always set the lifestyle type to the same value, but obviously we can write as complex code in the ProcessModel method as we would like. We can now configure the container like this:

var container
= new WindsorContainer();

container.Kernel.ComponentModelBuilder

    .AddContributor(new SingletonEqualizer());

container.Install(new FooInstaller());

With this configuration we will now get the same instance of Foo every time we Resolve IFoo.

We did I need this? Because my application is a web application and I’m using the PerWebRequest lifestyle in a number of places. However, I needed to spin up a second container that would compose object hierarchies for a background process. This background process needs the same component configuration as the rest of the application, but can’t use the PerWebRequest lifestyle as there will be no web request available to the background process. Hence the need to change lifestyles across the board.

Why I’m migrating from MSTest to xUnit.net

Mark Seemann — Mon, 26 Apr 2010 04:30:49 GMT

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

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

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

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

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

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

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

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

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

AutoFixture 1.1

Mark Seemann — Sat, 10 Apr 2010 10:25:23 GMT

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

The 1.1 release page has more details about this particular release, but essentially this is the RC promoted to release status.

Release 1.1 is an interim release that addresses a few issues that appeared since the release of version 1.0. Work continues on AutoFixture 2.0 in parallel.

Dependency Injection is Loose Coupling

Mark Seemann — Wed, 07 Apr 2010 19:49:11 GMT

It seems to me that I’ve lately encountered a particular mindset towards Dependency Injection (DI). People seem to think that it’s only really good for replacing one data access implementation with another. Once you get to that point, you know that the following argument isn’t far behind:

“That’s all well and good, but we know for certain that we will never exchange [insert name of RDBMS here] with anything else in this application.”

Apart from the hubris of making such a bold statement about the future of any software endeavor, such a statement reveals the narrow view on DI that its only purpose is for replacing data access components – and perhaps for unit testing.

Those are relevant reasons for using DI, but they are only some of the reasons. Let’s briefly revisit why we employ DI.

We use DI to enable loose coupling.

DI is only a means to an end. Even if you never intend to replace your database and even if you never want to write a single unit test, DI still offers benefits in form of a more maintainable code base. The loose coupling gives you better separation of concerns because it allows you to apply the Open/Closed Principle.

Example coming right up:

Imagine that we need to implement a PrécisViewModel class with a TopSellers property that returns an IEnumerable<string>. To implement this class, we have a data access component. Let’s use the ubiquitous Repository pattern and define IProductRepository to see where that leads us:

public interface IProductRepository

    IEnumerable<Product>
SelectTopSellers();

We can now implement PrécisViewModel like this:

public class PrécisViewModel

    private readonly IProductRepository repository;

    public PrécisViewModel(IProductRepository repository)

        if (repository
== null)

            throw new ArgumentNullException("repository");

        this.repository
= repository;

    public IEnumerable<string>
TopSellers

get

            var topSellers
=

                this.repository.SelectTopSellers();

            return from p in topSellers

                   select p.Name;

Nothing fancy is going on here. It’s just straight Constructor Injection at work.

Obviously, we can now implement and use a SQL Server-based repository:

var repository
= new SqlProductRepository();

var vm
= new PrécisViewModel(repository);

So what does all this loose coupling buy us? It doesn’t seem to help us a lot.

The real benefit is not yet apparent, but it should become more obvious when we start adding requirements. Let’s start with some caching. It turns out that the SelectTopSellers implementation is slow, so we would like to add some caching somewhere.

Where should we add this caching functionality? Without loose coupling, we would more or less be constrained to adding it to either PrécisViewModel or SqlProductRepository, but both have issues:

First of all we would be violating the Single Responsibility Principle (SRP) in both cases.
If we implement caching in PrécisViewModel, other consumers of the SelectTopSellers would not benefit from it.
If we implement caching in SqlProductRepository, it wouldn’t be available for any other IProductRepository implementations.

Since the premise for this post is that we will never use any other database than SQL Server, implementing caching directly in SqlProductRepository sounds like the correct choice, but we would still be violating the SRP, and thus making our code more difficult to maintain.

A better solution is to introduce a caching Decorator like this one:

public class CachingProductRepository : IProductRepository

    private readonly ICache cache;

    private readonly IProductRepository repository;

    public CachingProductRepository(

        IProductRepository repository, ICache cache)

        if (repository
== null)

            throw new ArgumentNullException("repository");

        if (cache
== null)

            throw new ArgumentNullException("cache");

        this.cache
= cache;

        this.repository
= repository;

   
#region IProductRepository Members

    public IEnumerable<Product>
SelectTopSellers()

        return this.cache

            .Retrieve<IEnumerable<Product>>("topSellers",

                this.repository.SelectTopSellers);

   
#endregion

For completeness sake is here the definition of ICache:

public interface ICache

    T Retrieve<T>(string key, Func<T>
readThrough);

The point is that CachingProductRepository extends any IProductRepository we provide to it (including SqlProductRepository) without modifying it. Thus, we have satisfied both the OCP and the SRP.

Just to drive home the point, let us assume that we also wish to record execution times for various methods for purposes of SLA compliance. We can do this by introducing yet another Decorator:

public class PerformanceMeasuringProductRepository :

    IProductRepository

    private readonly IProductRepository repository;

    private readonly IStopwatch stopwatch;

    public PerformanceMeasuringProductRepository(

        IProductRepository repository,

        IStopwatch stopwatch)

        if (repository
== null)

            throw new ArgumentNullException("repository");

        if (stopwatch
== null)

            throw new ArgumentNullException("stopwatch");

        this.repository
= repository;

        this.stopwatch
= stopwatch;

   
#region IProductRepository Members

    public IEnumerable<Product>
SelectTopSellers()

        var timer
= this.stopwatch

            .StartMeasuring("SelectTopSellers");

        var topSellers
=

            this.repository.SelectTopSellers();

        timer.StopMeasuring();

        return topSellers;

   
#endregion

Once again, we modified neither SqlProductRepository nor CachingProductRepository to introduce this new feature. We can implement security and auditing features by following the same principle.

To me, this is what loose coupling (and DI) is all about. That we can also replace data access components and unit test using dynamic mocks are very fortunate side effects, but the loose coupling is valuable in itself because it enables us to write more maintainable code.

We don’t even need a DI Container to wire up all these repositories (although it sure would be helpful). Here’s how we can do it with Poor Man’s DI:

IProductRepository repository
=

    new PerformanceMeasuringProductRepository(

        new CachingProductRepository(

            new SqlProductRepository(), new Cache()

),

        new RealStopwatch()

);

var vm
= new PrécisViewModel(repository);

The next time someone on your team claims that you don’t need DI because the choice of RDBMS is fixed, you can tell them that it’s irrelevant. The choice is between DI and Spaghetti Code.

Mapping types with AutoFixture

Mark Seemann — Tue, 06 Apr 2010 05:22:32 GMT

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

[TestMethod]

public void AddWillAddToBasket()

    //
Fixture setup

    var fixture
= new Fixture();

    fixture.Register<IPizzaMap>(

        fixture.CreateAnonymous<PizzaMap>);

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

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

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

    //
Exercise system

    sut.Add(pizza);

    //
Verify outcome

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

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

    //
Teardown

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

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

We see that happening in this line of code:

fixture.Register<IPizzaMap>(

    fixture.CreateAnonymous<PizzaMap>);

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

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

public static void Register<TAbstract,
TConcrete>(

    this Fixture fixture) where TConcrete
: TAbstract

    fixture.Register<TAbstract>(() =>

        fixture.CreateAnonymous<TConcrete>());

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

fixture.Register<IPizzaMap, PizzaMap>();

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

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

AutoFixture 1.1 RC1

Mark Seemann — Fri, 02 Apr 2010 06:44:27 GMT

AutoFixture 1.1 Release Candidate 1 is now available on the CodePlex site.

Users are encouraged to evaluate this RC and submit feedback. If no bugs or issues are reported within the next week, we will promote RC1 to version 1.1.

The release page has more details about this particular release.

Freezing mocks

Mark Seemann — Sat, 27 Mar 2010 13:27:02 GMT

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

var mapMock
= new Mock<IPizzaMap>();

fixture.Register(mapMock.Object);

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

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

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

public static Mock<T>
FreezeMoq<T>(this Fixture fixture)

    where T
: class

    var td
= new Mock<T>();

    fixture.Register(td.Object);

    return td;

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

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

[TestMethod]

public void AddWillPipeMapCorrectly_FreezeMoq()

    //
Fixture setup

    var fixture
= new Fixture();

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

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

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

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

    //
Exercise system

    sut.Add(pizza);

    //
Verify outcome

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

    //
Teardown

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

More about frozen pizza

Mark Seemann — Fri, 26 Mar 2010 22:01:42 GMT

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

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

[TestMethod]

public void AddWillPipeMapCorrectly()

    //
Fixture setup

    var fixture
= new Fixture();

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

    var mapMock
= new Mock<IPizzaMap>();

    fixture.Register(mapMock.Object);

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

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

    //
Exercise system

    sut.Add(pizza);

    //
Verify outcome

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

    //
Teardown

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

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

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

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

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

public class BasketPresenter

    private readonly Basket basket;

    private readonly IPizzaMap map;

    public BasketPresenter(Basket basket, IPizzaMap map)

        if (basket
== null)

            throw new ArgumentNullException("basket");

        if (map
== null)

            throw new ArgumentNullException("map");

        this.basket
= basket;

        this.map
= map;

    public void Add(PizzaPresenter presenter)

        this.map.Pipe(presenter, this.basket.Add);

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

Coming up: more fun with the Freeze concept!

AutoFixture Freeze

Mark Seemann — Wed, 17 Mar 2010 21:54:53 GMT

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

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

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

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

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

[TestMethod]

public void NameIsCorrect()

    //
Fixture setup

    var fixture
= new Fixture();

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

    fixture.Register(expectedName);

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

    //
Exercise system

    string result
= sut.Name;

    //
Verify outcome

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

    //
Teardown

The important lines are these two:

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

fixture.Register(expectedName);

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

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

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

[TestMethod]

public void NameIsCorrect_Freeze()

    //
Fixture setup

    var fixture
= new Fixture();

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

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

    //
Exercise system

    string result
= sut.Name;

    //
Verify outcome

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

    //
Teardown

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

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

For completeness sake, here’s the Pizza class:

public class Pizza

    private readonly string name;

    public Pizza(string name)

        if (name
== null)

            throw new ArgumentNullException("name");

        this.name
= name;

    public string Name

        get { return this.name;
}

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

CNUG TDD talk

Mark Seemann — Mon, 08 Feb 2010 19:15:41 GMT

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 an Anti-Pattern

Mark Seemann — Wed, 03 Feb 2010 21:49:39 GMT

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

    public void 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

    private readonly static Dictionary<Type, Func<object>>

        services = new Dictionary<Type, Func<object>>();

    public static void Register<T>(Func<T>
resolver)

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

    public static T
Resolve<T>()

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

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

var sut
= new OrderProcessor();

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

    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

    private readonly static Dictionary<Type, Func<object>>

        services = new Dictionary<Type, Func<object>>();

    public static void Register<T>(Func<T>
resolver)

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

    public T
Resolve<T>()

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

    public static void 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

    private readonly Dictionary<Type, Func<object>>
services;

    public Locator()

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

    public void 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

    private readonly IServiceLocator locator;

    public OrderProcessor(IServiceLocator locator)

        if (locator
== null)

            throw new ArgumentNullException("locator");

        this.locator
= locator;

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

var locator
= new Locator();

var sut
= new OrderProcessor(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.

Refactoring to Aggregate Services

Mark Seemann — Tue, 02 Feb 2010 20:56:44 GMT

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

    private readonly IUserContext _userContext;

    private readonly IRateExchange _exchange;

    private readonly IAccountsReceivable _receivable;

    public OrderCollector(IAccountsReceivable receivable,

                          IRateExchange exchange,

                          IUserContext userContext)

        _receivable = receivable;

        _exchange = exchange;

        _userContext = userContext;

   
#region IOrderCollector Members

    public void 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:

Analyze how dependencies interact to identify clusters of behavior.
Extract an interface from these clusters.
Copy the original implementation to a class that implements the new interface.
Inject the new interface into the consumer.
Replace the original implementation with a call the new dependency.
Remove the redundant dependencies.
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

Mark Seemann — Wed, 27 Jan 2010 22:54:58 GMT

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!

What's so dangerous about a DI attribute?

Mark Seemann — Wed, 27 Jan 2010 19:36:34 GMT

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.

IWindsorInstaller

Mark Seemann — Tue, 26 Jan 2010 19:24:51 GMT

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:

public class BillingContainerInstaller : IWindsorInstaller

{

    #region IWindsorInstaller Members

    public void Install(IWindsorContainer container,

        IConfigurationStore store)

    {

        container.AddComponent<TransactionLog, 

            DatabaseTransactionLog>();

        container.AddComponent<CreditCardProcessor,

            MyCreditCardProcessor>();

        container.AddComponent<BillingService>();

    }

    #endregion

}

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:

var container = new WindsorContainer();

container.Install(new BillingContainerInstaller());

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

Dependency Injection Inversion in .NET

Mark Seemann — Mon, 25 Jan 2010 20:48:27 GMT

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#:

public class BillingService

{

    private readonly CreditCardProcessor processor;

    private readonly TransactionLog transactionLog;

    public BillingService(CreditCardProcessor processor,

        TransactionLog transactionLog)

    {

        if (processor
== null)

        {

            throw new ArgumentNullException("processor");

        }

        if (transactionLog
== null)

        {

            throw new ArgumentNullException("transactionLog");

        }

        this.processor
= processor;

        this.transactionLog
= transactionLog;

    }

    public void ProcessCharge(int amount, string id)

    {

        var approval
= this.processor.Approve(amount, id);

        this.transactionLog.Log(string.Format(

            "Transaction
by {0} for {1} {2}", id, amount, 

            this.GetApprovalCode(approval)));

    }

    private string GetApprovalCode(bool approval)

    {

        return approval
? "approved" : "denied";

    }

}

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:

public static void Main(string[]
args)

{

    var container = new WindsorContainer();

    Program.Configure(container);

    var billingService =

        container.Resolve<BillingService>();

    billingService.ProcessCharge(2034, "Bob");

}

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:

private static void Configure(WindsorContainer container)

{

    container.Register(Component

        .For<TransactionLog>()

        .ImplementedBy<DatabaseTransactionLog>());

    container.Register(Component

        .For<CreditCardProcessor>()

        .ImplementedBy<MyCreditCardProcessor>());

    container.Register(Component.For<BillingService>());

}

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 RC2

Mark Seemann — Wed, 20 Jan 2010 22:59:39 GMT

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.

Enabling DI for Lazy Components

Mark Seemann — Wed, 20 Jan 2010 18:08:36 GMT

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

    private readonly IOrderShipperFactory factory;

    private IOrderShipper shipper;

    public LazyOrderShipper2(IOrderShipperFactory factory)

        if (factory
== null)

            throw new ArgumentNullException("factory");

        this.factory
= factory;

   
#region IOrderShipper Members

    public void 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.

Rebuttal: Constructor over-injection anti-pattern

Mark Seemann — Wed, 20 Jan 2010 16:28:03 GMT

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

    private OrderShipper shipper;

   
#region IOrderShipper Members

    public void Ship(Order order)

        if (this.shipper
== null)

            this.shipper
= new OrderShipper();

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

    stopwatch.Start();

    var order
= new Order();

    var validator
= new Mock<IOrderValidator>();

    validator.Setup(v =>

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

    var shipper
= new LazyOrderShipper();

    var sut
= new OrderProcessor(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 RC1

Mark Seemann — Wed, 13 Jan 2010 22:48:13 GMT

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.

Anonymous Get

Mark Seemann — Mon, 04 Jan 2010 20:53:24 GMT

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:

object BindModel(ControllerContext controllerContext,

    ModelBindingContext bindingContext);

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.

[TestMethod]

public void BindModelWillReturnCorrectResult()

{

    // Fixture setup

    var fixture = new Fixture();

    fixture.Customize<ControllerContext>(ob
=>

        ob.OmitAutoProperties());

    var value = fixture.CreateAnonymous("Value");

    var bindingContext = new ModelBindingContext();

    bindingContext.ValueProvider = 

        new Dictionary<string, ValueProviderResult>();

    bindingContext.ValueProvider["MyValue"]
= 

        new ValueProviderResult(value,
value, 

            CultureInfo.CurrentCulture);

    var expectedResult = 

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

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

    // Exercise system

    var result = fixture.Get((ControllerContext cc)
=>

        sut.BindModel(cc, bindingContext));

    // Verify outcome

    Assert.AreEqual(expectedResult,
result, "BindModel");

    // Teardown

}

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:

var result = fixture.Get((ControllerContext cc)
=>

    sut.BindModel(cc, bindingContext));

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:

public TResult Get<T, TResult>(Func<T,
TResult> function);

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.

MEF TechTalk with me

Mark Seemann — Sun, 20 Dec 2009 19:56:33 GMT

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.

Wiring ASP.NET MVC Error Handling with Castle Windsor

Mark Seemann — Mon, 14 Dec 2009 06:59:32 GMT

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.

LoggingExceptionFilter

Mark Seemann — Mon, 07 Dec 2009 06:20:27 GMT

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

    private readonly IExceptionFilter filter;

    private readonly ILogWriter logWriter;

    public LoggingExceptionFilter(IExceptionFilter filter,

        ILogWriter logWriter)

        if (filter
== null)

            throw new ArgumentNullException("filter");

        if (logWriter
== null)

            throw new ArgumentNullException("logWriter");

        this.filter
= filter;

        this.logWriter
= logWriter;

   
#region IExceptionFilter Members

    public void 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 =

    new ErrorHandlingControllerActionInvoker(

        new LoggingExceptionFilter(

            new HandleErrorAttribute(),
logWriter));

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

Building and assigning arrays with AutoFixture

Mark Seemann — Sat, 05 Dec 2009 00:41:45 GMT

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

    public MyClassB[]
Items;

    public MyClassC C;

    public MyClassD 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.

Global Error Handling in ASP.NET MVC

Mark Seemann — Tue, 01 Dec 2009 06:37:01 GMT

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.

[HandleError]

public class AccountController : Controller {
}

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:

public class ErrorHandlingActionInvoker :

    ControllerActionInvoker

{

    private readonly IExceptionFilter filter;

    public ErrorHandlingActionInvoker(

        IExceptionFilter filter)

    {

        if (filter
== null)

        {

            throw new ArgumentNullException("filter");

        }

        this.filter
= filter;

    }

    protected override FilterInfo GetFilters(

        ControllerContext controllerContext,

        ActionDescriptor actionDescriptor)

    {

        var filterInfo
= 

            base.GetFilters(controllerContext, 

            actionDescriptor);

        filterInfo.ExceptionFilters.Add(this.filter);

        return filterInfo;

    }

}

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:

public class ErrorHandlingControllerFactory : 

    DefaultControllerFactory

{

    public override IController CreateController(

        RequestContext requestContext,

        string controllerName)

    {

        var controller
= 

            base.CreateController(requestContext,

            controllerName);

        var c
= controller as Controller;

        if (c
!= null)

        {

            c.ActionInvoker
= 

                new ErrorHandlingActionInvoker(

                    new HandleErrorAttribute());

        }

        return controller;

    }

}

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:

ControllerBuilder.Current.SetControllerFactory(

    new ErrorHandlingControllerFactory());

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:

<customErrors mode="On" />

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

Anonymous Do

Mark Seemann — Thu, 26 Nov 2009 21:23:46 GMT

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:

void Execute(object 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:

[TestMethod]

public void FooWillUpdateMessage()

{

    // Fixture setup

    var fixture = new Fixture();

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

    // Exercise system

    fixture.Do((object parameter)
=> 

        sut.FooCommand.Execute(parameter));

    // Verify outcome

    Assert.AreEqual("Foo",
sut.Message, "Message");

    // Teardown

}

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:

public void Do<T>(Action<T>
action);

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.

Dependency Injection Podcast with me

Mark Seemann — Tue, 17 Nov 2009 18:58:47 GMT

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.

Using Castle Windsor's PerWebRequest lifestyle with ASP.NET MVC on IIS7

Mark Seemann — Tue, 17 Nov 2009 12:44:37 GMT

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.

Creating length-constrained strings with AutoFixture

Mark Seemann — Sat, 07 Nov 2009 19:56:05 GMT

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

    private readonly int minimumLength;

    private readonly int maximumLength;

    public ConstrainedStringGenerator(int minimumLength,

        int maximumLength)

        if (maximumLength
< 0)

            throw new ArgumentOutOfRangeException("...");

        if (minimumLength
> maximumLength)

            throw new ArgumentOutOfRangeException("...");

        this.minimumLength
= minimumLength;

        this.maximumLength
= maximumLength;

    public string 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

    public static ObjectBuilder<T>
With<T>(

        this ObjectBuilder<T>
ob,

        Expression<Func<T, string>>
propertyPicker,

        int minimumLength,

        int maximumLength)

        var me
= (MemberExpression)propertyPicker.Body;

        var name
= me.Member.Name;

        var generator
=

            new ConstrainedStringGenerator(

                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

Mark Seemann — Sat, 31 Oct 2009 08:59:43 GMT

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.

Anonymous With

Mark Seemann — Mon, 26 Oct 2009 20:26:49 GMT

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

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

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

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

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

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

[TestMethod]

public void ProfileWillReturnResultWithCorrectUserName()

    //
Fixture setup

    var fixture
= new Fixture();

    fixture.Customize<ControllerContext>(ob
=> ob

        .OmitAutoProperties()

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

    var expectedUserName
=

        fixture.CreateAnonymous("UserName");

    var httpCtxStub
= new Mock<HttpContextBase>();

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

        new GenericPrincipal(

            new GenericIdentity(expectedUserName), null));

    fixture.Register(httpCtxStub.Object);

    var sut
= fixture.Build<MyController>()

        .OmitAutoProperties()

        .With(c => c.ControllerContext)

        .CreateAnonymous();

    //
Exercise system

    ViewResult result
= sut.Profile();

    //
Verify outcome

    var actual
= result.ViewData.Model;

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

    //
Teardown

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

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

Let me highlight some parts of the test.

fixture.Customize<ControllerContext>(ob
=> ob

    .OmitAutoProperties()

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

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

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

var httpCtxStub
= new Mock<HttpContextBase>();

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

    new GenericPrincipal(

        new GenericIdentity(expectedUserName), null));

fixture.Register(httpCtxStub.Object);

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

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

var sut
= fixture.Build<MyController>()

    .OmitAutoProperties()

    .With(c => c.ControllerContext)

    .CreateAnonymous();

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

public class MyController : Controller

    public ViewResult Profile()

        object userName
= this.User.Identity.Name;

        return this.View(userName);

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

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

WCF Podcast with me

Mark Seemann — Sat, 24 Oct 2009 01:52:18 GMT

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

Writing a book

Mark Seemann — Mon, 05 Oct 2009 18:13:50 GMT

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.

SOLID or COLDS?

Mark Seemann — Tue, 29 Sep 2009 19:38:42 GMT

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.

Customizing A Type's Builder With AutoFixture

Mark Seemann — Tue, 22 Sep 2009 14:53:48 GMT

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

add the anonymous MyClass instance to the list of AvailableItems
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.

AutoFixture .8.6 Released

Mark Seemann — Mon, 21 Sep 2009 17:37:36 GMT

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.

Self-updating AJAX links with ASP.NET MVC

Mark Seemann — Mon, 07 Sep 2009 18:14:39 GMT

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

    return this.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"]
},

    new AjaxOptions {
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();

    return this.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.

AutoFixture .8.5 Released

Mark Seemann — Wed, 02 Sep 2009 20:21:13 GMT

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.