4

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?

Ian Warburton
  • 15,170
  • 23
  • 107
  • 189

1 Answers1

7

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"; }
        }
    }

}
Zodman
  • 3,178
  • 2
  • 32
  • 38
AlanT
  • 3,627
  • 20
  • 28
  • 1
    I found an article that said that when doing integration testing one *should* use the app's IoC container so that the integration of parts that one is testing is the same as that used by the live app. – Ian Warburton Aug 22 '12 at 13:20
  • 1
    @Ian Warburton Yep, for integration tests I agree. I got heavily focussed on unit testing in the answer. It can happen that we have nice integration tests which pass with flying colours but the actual app fails because the live IOC has not been wired up correctly. A common container setup which is used for both tests and production is good as long as one can swap out the leaf objects when integration testing - e.g replace a network service with a network serviec mock/stub – AlanT Aug 23 '12 at 08:49
  • How would you do that? Inherit from the container set-up class and override methods that add the leaf objects? – Ian Warburton Aug 23 '12 at 14:28
  • 1
    @Ian Warburton Updated the answer to give an example – AlanT Aug 24 '12 at 09:15
  • That's interesting. So you are overwriting an earlier registration. I'm still more into my idea though of, say, CreateContainerWithMockedExternalDependencies inheriting from CreateContainerCore and overriding methods such that mocks get used. I suppose the problem there though is that you could end up with an ever increasing number of methods to override. – Ian Warburton Aug 30 '12 at 23:52
  • @Ian Warburton The other version we have used to to wrap the CreateContainerCore() with CreateContainerWithReaDependencies() for production or CreateContainerWithMockedDependencies() for test. We used this before we realised that overwriting the the registrations worked. It's just a style thing but I tend to favour wrapping (decorating) and composing over inheriting (seen to many examples of inheritance gone made esp. back in C++ days :? ) The nice thing about overwriting the registrations is that for a particular test set one needs only replace the relevant dependencies. – AlanT Aug 31 '12 at 08:31