Using Windsor as an auto-mocking container

One of my former colleagues blogged about using AutoFixture as an auto-mocking container the other day, which got me thinking about auto-mocking with Windsor.

Although I’ve never used auto-mocking myself, a few months ago, I answered a question on StackOverflow, hinting at how auto-mocking could be accomplished with Castle Windsor. I didn’t provide any example code though, so this post will show a more complete solution on how auto-mocking can be implemented with Windsor and Rhino Mocks1.

A lazy component loader to generate the mocks

First, I create a simple ILazyComponentLoader that lazily registers a Rhino Mocks instance when a particular service is requested – like so:

public class AutoMockingLazyComponentLoader : ILazyComponentLoader
{
    public IRegistration Load(string key, Type service, IDictionary arguments)
    {
        return Component.For(service).Instance(MockRepository.GenerateMock(service, new Type[0]));
    }
}

- real simple. Windsor’s default lifestyle is singleton, which ensures that subsequent calls for the same service will give me the same mock instance.

Test fixture base class

Then I create a test fixture base class, which is supposed to act as exactly that: a fixture for the SUT:

public abstract class AutoMockingFixtureFor<TAppService>
{
    IWindsorContainer container;
 
    protected TAppService service;
 
    [SetUp]
    public void SetUp()
    {
        container = new WindsorContainer()
            .Register(Component.For<ILazyComponentLoader>().ImplementedBy<AutoMockingLazyComponentLoader>(),
                      Component.For<TAppService>());
 
        // build sut and inject mocks for all dependencies
        service = container.Resolve<TAppService>();
 
        DoSetUp();
    }
 
    protected virtual void DoSetUp() { }
 
    [TearDown]
    public void TearDown()
    {
        DoTearDown();
 
        container.Dispose()
    }
 
    protected virtual void DoTearDown() { }
 
    protected TDependency Dep<TDependency>()
    {
        return container.Resolve<TDependency>();
    }
 
    protected TMock Mock<TMock>() where TMock : class
    {
        return MockRepository.GenerateMock<TMock>();
    }
}

As you can see, my SetUp method creates a new WindsorContainer, registering nothing but my AutoMockingLazyComponentLoader and TAppService – the SUT type. It then uses the container to instantiate the SUT, storing it away in a protected instance variable for test cases to work on.

I included DoSetUp and DoTearDown methods for my test fixtures to override in case they need to – but in most cases, they should not be used because of the coupling they introduce between test cases.

Lastly, I have two methods: Dep, which allows me to access an injected service type (short for “dependency”), and Mock which allows me to generate a new mock object in case I need to mock something other than my SUT’s dependencies.

How to write a new test fixture

As a result of this, a test fixture for something called HandleUpdateDisturbanceForecast is reduced to something like this:

[TestFixture]
public class TestOfHandleUpdateDisturbanceForecast : AutoMockingFixtureFor<HandleUpdateDisturbanceForecast>
{
    [Test]
    public void UpdatesDriverWithReceivedObservableForecast()
    {
        // Arrange
        var now = 19.March(1979).At(12.Hours());
        var localUnit = new GenericDriver();
        Dep<IProvidesSiteToStartUp>().Stub(p => p.GetLocalUnitByAlias("ali")).Return(localUnit);
 
        // Act
        service.Handle(new UpdateDisturbanceForecast
                            {
                                LocalUnitAlias = "ali",
                                DisturbanceForecast = new List<DisturbancePlanEntry>
                                                            {
                                                                new DisturbancePlanEntry {Time = now, Disturbance = 2},
                                                            }
                            });
 
        // Assert
        var forecast = localUnit.DisturbanceForecast;
        Assert.AreEqual(1, forecast.Count);
        Assert.AreEqual(now, forecast[0].Time);
        Assert.AreEqual(2, forecast[0].Value);
    }
}

- which I think looks pretty slick. And yes, this is an actual test case from something we’re building – doesn’t matter what it’s doing, just wanted to show an actual example.

It’s not like I’m saving a huge amount of coding here – I usually only instantiate my SUT in the SetUp method of my test fixtures, but I like how the “fixed style” of AutoMockingFixtureFor encourages application services to follow a pattern that makes for easy IoC and testing. And the fixture is relieved of almost all clutter that does not directly relate to the thing being tested.

  1. I realize that all the cool kids are using other mocking libraries these days. I’m still using Rhino though, but it should be a fairly trivial task to “port” this solution to another mocking library. ↩