Can I use an IoC container in unit/integration tests? - unit-testing

Question

I've got an IoC container doing some complicated object construction when resolving some interfaces. I want to use implementations of these interfaces in my unit/integration tests. Is there anything wrong with resolving these interfaces in the tests using the IoC container or is it expected that one should build up instances manually in this situation?

Answer 1

When we are unit testing a class we are concerned with 'does the class do what we want it to do'.
Our starting point is a fully constructed instance; how we got there is not a unit testing question though it may be considered an integration testing question.
Say we have,
A
A(IB b, IC c)
B : IB
B(ID d)
C : IC
D : ID
Where:
IB is an interface for B,
IC is an interface for C, and
ID is an interface for D.
When unit testing A, the fact that B uses ID should be moot (if it is not then we should look at our interfaces. Having A access IB.D.xxx() is not good), all we need to do is provide A with some implementation (mocked/stubbed) of IB and IC.
As far as the unit tests for A are concerned, whether the A instance is created by hand or by a container is not important. We get the same object either way.
As long as we are passing in mocks as the first level dependencies then there is no saving when using a container over creating the object by hand. The saving only happens when we are creating object graphs using the IOC, but if we are doing this then we are into integration testing. This is not necessarily a bad thing but we need to be clear on our goals.
When unit testing the above we create unit testing for
D
C
B (passing in a mocked/stubbed ID)
A (passing in mocked/stubbed IC and IB)
When unit testing A we do not need the correct answer from D to be passed through B up to A.
All we care is that the logic in A works as expected, say, A calls IB.x() with the parameters y and z and returns the result of IB.x(). If we are checking that we get the correct answer (say, one which depends on logic in D) then we are past unit testing and into integration testing.
Bottom Line
It does not matter whether or not the unit under test was created by an IOC container or by hand as long as we are properly isolating the unit under test. If we are using the container to create an object graph then the odds are good that we are into integration testing (and/or have problems with too much coupling between classes - A calling IB.D.xxx())
Mocking for Integration Tests
Caveat: Some of this following is dependent upon the IOC container in use. When using Unity, the last registration 'wins'. I do not know that this holds true for others.
In the minimalist system under question we have
A
A (IB b)
B : IB
B is our 'leaf'. It talks to the outside world (say, reads from a network stream).
When Integration testing, we want to mock this.
For the live system, we set up the ServiceLocator using CreateContainerCore().
This includes the registration of the 'live' implementation of IB.
When executing integration tests that require a mocked version of IB we set up the container using CreateContainerWithMockedExternalDependencies() which wraps CreateContainerCore() and registering a mocked object for IB.
The code below is heavily simplified but the shape extends out to as many classes and dependencies as required. In practice, we have a base test class that aids setting up the service locator, mocking/stubbing classes, accessing the mocks for verification purposes and other house keeping (e.g.so that each test doesn't need to explicitly set the ServiceLocator provider)
[TestClass]
public class IocIntegrationSetupFixture {
[TestMethod]
public void MockedB() {
ServiceLocator.SetLocatorProvider(() => new UnityServiceLocator(CreateContainerWithMockedExternalDependencies()));
var a = ServiceLocator.Current.GetInstance<A>();
Assert.AreEqual("Mocked B", a.GetMessage());
}
[TestMethod]
public void LiveB() {
ServiceLocator.SetLocatorProvider(() => new UnityServiceLocator(CreateContainerCore()));
var a = ServiceLocator.Current.GetInstance<A>();
Assert.AreEqual("Live B", a.GetMessage());
}
private IUnityContainer CreateContainerCore() {
var container = new UnityContainer();
container.RegisterType<IB, B>(new ContainerControlledLifetimeManager());
return container;
}
private IUnityContainer CreateContainerWithMockedExternalDependencies() {
var container = CreateContainerCore();
var mockedB = new Mock<IB>();
mockedB.SetupGet(mk => mk.Message).Returns("Mocked B");
container.RegisterInstance<IB>(mockedB.Object);
return container;
}
public class A {
private IB _b;
public A(IB b) {
_b = b;
}
public string GetMessage() {
return _b.Message;
}
}
public interface IB {
string Message { get; }
}
private class B : IB {
public string Message {
get { return "Live B"; }
}
}
}