To make your code testable the pattern to use is that of Dependency Injection. DI is nothing more than injecting all dependencies of a class instance through the constructor (or setters if you wish, but less intuitive when reading the code, and doesn’t guarantee all dependencies are set). For example if you have a controller that uses a factory and a repository you can both inject them into the constructor as follows:

public class Controller
{
	private readonly IFactory factory;
	private readonly IRepository repository;

	public Controller(IFactory factory, IRepository repository)
	{
		this.factory = factory;
		this.repository = repository;
	}
}

When looking at the constructor you immediately see on which components this class depends. Using interfaces makes testing even more simple, because then we can easily mock the dependencies. Creating an instance of the controller will look as follows:

IFactory factory = new Factory();
IRepository repository = new Repository();

Controller controller = new Controller(factory, repository);

Once your nesting of dependencies gets bigger, setting up your instances becomes quite cumbersome. This causes you to rethink before you add another dependency to a class. This hinders testability, so you would really want adding another dependency to be a piece of cake.

Enters Inversion Of Control container. The IOC container is some software that handles initialization of all your dependencies. StructureMap is on of the longest available ones for .Net. Others are Castle Windsor, Spring.NET, Unity, Ninject and others. What makes StructureMap very pleasant to work with is it’s extra facilities for testing.

First an example of how you use StructureMap to initialize your instances.

To setup which classes to use for which interfaces you do the following initialization once:

ObjectFactory.Initialize(x =>
	{
		x.For<IFactory>().Use<Factory>();
		x.For<IRepository>().Use<Repository>();
	});

Then every time you need an instance of your controller you can use the following code:

Controller controller = ObjectFactory.GetInstance<Controller>();

StructureMap looks at the constructor of class Controller and sees it’s dependent on an IFactory and IRepository. It knows which concrete classes to use for these interfaces, so it creates those first and then creates the Controller instance by injecting them into the constructor.

StructureMap in MVC

In a standard MVC project your controllers are required to have a parameterless constructor, which is used to initialize them. Of course this is in conflict with the Dependency Injection we want to use the make our code testable and easy to setup with StructureMap. However MVC is extensible on this point, and we can provide our own ControllerFactory, which looks as follows:

public class StructureMapControllerFactory : DefaultControllerFactory
{
	protected override IController GetControllerInstance(Type controllerType)
	{
		if (controllerType == null)
		{
			return base.GetControllerInstance(controllerType);
		}

		try
		{
			return ObjectFactory.GetInstance(controllerType) as Controller;
		}
		catch (StructureMapException exception)
		{
			// log an error with the exception and ObjectFactory.WhatDoIHave()
			throw;
		}
	}
}

In MVC 2 the signature of method GetControllerInstance looks a little different, so our StructureMapControllerFactory will be adjusted correspondingly:

public class StructureMapControllerFactory : DefaultControllerFactory
{
	protected override IController GetControllerInstance(RequestContext requestContext,
														 Type controllerType)
	{
		if (controllerType == null)
		{
			return base.GetControllerInstance(requestContext, controllerType);
		}

		try
		{
			return ObjectFactory.GetInstance(controllerType) as Controller;
		}
		catch (StructureMapException exception)
		{
			// log an error with the exception and ObjectFactory.WhatDoIHave()
			throw;
		}
	}
}

This factory makes sure that StructureMap initializes your controllers. Now to make MVC use this factory we add the following code to the Global.asax.cs:

protected void Application_Start()
{
	// initialize structuremap container
	StructureMapBootstrapper.Bootstrap();

	// let structuremap handle creating controllers
	ControllerBuilder.Current.SetControllerFactory(new StructureMapControllerFactory());
}

On the last line we set the factory. The first line calls the bootstrapper, which does the initialization of StructureMap.

public class StructureMapBootstrapper : IBootstrapper
{
	private static bool hasStarted;

	public void BootstrapStructureMap()
	{
		ObjectFactory.Initialize(x =>
		{
			x.For<ISessionHandler>().Use<SessionHandler>();
			x.For<ITempDataHandler>().Use<TempDataHandler>();

			x.ForSingletonOf<ICacheHandler>().Use<CacheHandler>();

			x.AddRegistry<FactoryRegistry>();
			x.AddRegistry<RepositoryRegistry>();
			x.AddRegistry<ServiceRegistry>();
		});
	}

	public static void Restart()
	{
		if (hasStarted)
		{
			ObjectFactory.ResetDefaults();
		}
		else
		{
			Bootstrap();
			hasStarted = true;
		}
	}

	public static void Bootstrap()
	{
		new StructureMapBootstrapper().BootstrapStructureMap();
	}
}

The highlighted ObjectFactory.Initialize part in the code above is the part that is custom for your project. Here you specify which concrete class to use for which interface. The initialization isn’t very fast, but only performed once in production code. For testing purposes this is to costly, so the restart action is provided.

You can also see the lines with AddRegistry: the registries that are added are a way to group your code, because otherwise the bootstrapper can become quite long. A definition of a registry:

public class FactoryRegistry : Registry
{
	public FactoryRegistry()
	{
		For<IInputModelFactory>().Use<InputModelFactory>();
		For<IViewModelFactory>().Use<ViewModelFactory>();
	}
}

The specific StructureMap code in your project only consists of the BootStrapper, the registries and the ControllerFactory. It’s best to try and avoid the use of ObjectFactory.GetInstance throughout your code as much as possible. It makes it harder to replace StructureMap if you want to, but more importantly it makes your code harder to test. One case where you’ll probably won’t manage without is in the case of attributes. The creation of attribute instances is done by MVC and needs a parameterless constructor as well. However we can’t replace the factory in this case.

Unfortunately we need an extra use of ObjectFactory.GetInstance, but we can do it within the constructor to keep it testable:

public class CustomAttribute : ActionFilterAttribute
{
	private readonly ISessionHandler sessionHandler;

	public CustomAttribute()
	: this(ObjectFactory.GetInstance<ISessionHandler>())
	{
	}

	public CustomAttribute(ISessionHandler sessionHandler)
	{
		this.sessionHandler = sessionHandler;
	}

If a class is created by StructureMap it defaults to the constructor with the most parameters.

Testing with AutoMocker

Okay, on to the reason I prefer StructureMap as an IOC container: AutoMocker. The RhinoAutoMocker creates an instance of the class under test and creates a Rhino Mock object for all (interfaced) dependencies. No more creation of mock objects yourself. And even more important you can add another dependency to a class without having to fix all tests that create an instance.

A test fixture will look as follows:

[TestFixture]
public class AdvertsControllerTests
{
	private RhinoAutoMocker<Controller> autoMocker;
	private Controller controller;

	[SetUp]
	public void Setup()
	{
		StructureMapBootstrapper.Restart();

		autoMocker = new RhinoAutoMocker<Controller>(MockMode.AAA);
		controller = autoMocker.ClassUnderTest;
	}

	[Test]
	public void CreatePostShouldCallFormHandlerForValidPost()
	{
		//Arrange
		FormEditModel editModel = new FormEditModel();
		autoMocker.Get<IFormHandler>().Expect(p => p.CreatePost(Arg<FormEditModel>.Is.Anything)).Return(true);

		//Act
		controller.CreatePost(editModel);

		//Assert
		autoMocker.Get<IFormHandler>().VerifyAllExpectations();
	}

The highlighted autoMocker.Get<IFormHandler>() lines retrieve a mock object and set expectations. So, per test you only have to set the dependencies neccessary for the code under test. A controller often has a lot of dependencies, but they’re not used by every action.