Question

I don’t think this was asked before, although it’s really hard to search for a term like unit test ioc container and not find a question about how to implement IoC in order to perform unit tests.

I would like to have unit tests against the IoC container itself basically because sometimes I have issues with the container (like you could with any other part of an application), and it’s pretty troublesome to test the resolution of dependencies merely debugging.

If I could introduce unit tests for these cases, I think it would save me a lot of trouble.

Update

Is something like this, not an Unit Test? Is it an integration test?

[TestClass]
public class IoC
{
    private IWindsorContainer _container;

    [TestInitialize]
    public void TestInit()
    {
        _container = new WindsorContainer();
        _container.Install(new WindsorInstaller());
    }

    [TestMethod]
    public void ContainerShouldResolve_MembershipProvider()
    {
        ContainerShouldResolve<IMembershipProvider>();
    }

    public void ContainerShouldResolve<T>()
    {
        T result = _container.Resolve<T>();
        Assert.IsInstanceOfType(result, typeof(T));
    }
}

The only real “not self-contained” reference is a connection string I had to wire into app.config. Also: when trying to resolve PerWebRequest lifestyle components I had to add the related httpModule, too.

By the way: by doing this I found out the source of my issue in little time compared to what it was taking me to debug it through using the web application.

Answer 1

This falls more into integration testing category. Your components registration might do all kinds of external systems calls (database, file system, network, services …) when resolved, and this is where unit testing ends.

One approach you can do to this kind of (integration) testing, is to simply resolve your application root type. This might not be complete (especially when your application does large bits of lazy loading), but is often good enough to spot missing bits.

Edit #2 (in response to OP edit)

Of course, it might be possible to do root-resolve test without actually touching any external systems mentioned, but there still might be lot of dependencies wiring and setting up going on real objects (as in, not fakes/stubs). This is many potential reasons to fail (I’d say even too many for unit test) and is up to developer to judge what testing category this falls into.

Doing component-resolve test (resolve that relates to much smaller scope) might be fine for unit test, but once again – it’s for developer to judge and it largely depends on what the objects do upon resolve. Most modern containers usually offer more than simple storage and this should be taken into account.

What I’m trying to say is, if you have say DaoModule and you want to verify it can be resolved from container, sure, this might be an unit test. But if resolving your DaoModule setups connection and queries DB to see if it is in valid state, you probably need to reconsider where such test would go.

Edit #1 (in response to OP comment under question)

I want to set up a test where I configure the container, throw an abstract type (or interface) at it, and have it correctly resolve to an expected type.

Basically, you want to verify whether your container works? Don’t do that. Simply pick a container that is tested and you can assume it can do its job. If you feel the need to unit test your 3rd party components, you really should be choosing different ones.