Unit Testing you Container Dependencies

When developing with an inversion of control container (I use Windsor) its sometimes difficult to detect if your instances in your container are creatable or not. A lot of times this is determined when you run the app, you’ll get an exception informing you that your object does not have all of its dependencies fulfilled.

Therefore…the real question is …

Did you register everything in the container? Or did you forget something?

I know from personal experience I’ve forgotten to register components many times so I started relying on unit tests to catch me when I failed.

 

How to Test that you Registrations are Creatable

This simple unit test will assert that your components are creatable.

[Test]
public void All_components_in_container_should_be_creatable()
{
	var kernel = new DefaultKernel();
	var handlers = new List<IHandler>();

	kernel.ComponentRegistered += (name, handler) => handlers.Add(handler);

	// Used in our Global.asax on App Start to register our components. 
	var app = new Application();
	
	// Same call that we make in Global asax
	app.RegisterComponents(kernel); 
	
	// If the container (kernel) cannot resolve the instance
	// an exception will be thrown and the test will fail
	handlers.ForEach(handler =>
						 {
							 if (handler.CurrentState == HandlerState.WaitingDependency)
								 kernel.Resolve(handler.ComponentModel.Name, handler.Service);
						 });
}

Code Explained

Background: In all of the apps I write now I have an Application.cs file. This file is responsible for bootstrapping the container and everything else the app needs to run (Logging, Diagnostics, Facilities, etc). Inside of this Application.cs file I have a “RegisterComponents” call which registers all of the required components in the container.

Therefore, the code above creates a new container (kernel) and then we create a list of IHandler’s. An IHandler is an interface in Windsor Container (the container I’m using here) that manages component state and coordinates its creation and destruction.

The next line is a sweet little lambda expression that says …

“When a component is registered in the container, I want to add its handler to a list of Handlers”

Which of course, is the list we just created.

The next few lines set up the application and register the components.

The last call in the test is where the magic happens.

We iterate over the list of handlers and check their CurrentState property. If the state of the component is still waiting for a dependency to be resolved (perhaps it has something injected into the constructor) we will then try to resolve the component with the name of the component and service type. If it can be resolved, it will resolve and nothing will happen (which is good). However… if the container _cannot_ resolve the component, an exception of type Castle.MicroKernel.Handler.HandlerException will be thrown.

The exception looks like this:

Castle.MicroKernel.Handlers.HandlerException: Can’t create component ‘Foo.Bar.OrderRepository’ as it has dependencies to be satisfied. 
‘Foo.Bar.OrderRepository is waiting for the following dependencies: 
Keys (components with specific keys)

– dataStore which was not registered. 
– dataMapper which was not registered. 

As we can see above, the “Foo.Bar.OrderRepository” could not be resolved as the container could not find the “dataStore” parameter, or the “dataMapper” attribute.

At this point your test will fail and you’ll see that you have an issue with your container set up. Investigate, fix and retest!