Which is a good approach to test Ninject bindings?

Question

We use ninject in all our projects, and as you will know, sometimes it becomes hard to test if the kernel would be able to resolve every type at execution time, because some

Answer 1

Based on Owen's answer but that was not working for me as is. what I had to do was pass the new instance of my dependencies into a new kernel instance and at that point the Bindings property was populated.

    [TestMethod]
    public void TestBindings
    {
        var dependencies = new MyDependencies();
        var kernel = new StandardKernel(dependencies);

        foreach (var binding in dependencies.Bindings)
        {
            kernel.Get(binding.Service);
        }
    }

Also I chose to use kernal.Get so that if the service was not able to be resolved then the test would fail because of the error thrown as well as show the missing bindings in the message

Answer 2

So, what I'm asking here is how can I know that my kernel, after loading all modules and bindings, will be able to resolve every type ? Do you do any kind of Unit Test?

I test this by looping over each of the bindings in my module(s) and checking that the Kernel can return something for them:

[Test]
public void AllModuleBindingsTest()
{
    var kernel = new StandardKernel(new MyNinjectModule())
    foreach (var binding in new MyNinjectModule().Bindings)
    {
        var result = kernel.Get(binding.Service);
        Assert.NotNull(result, $"Could not get {binding.Service}");
    }
}

Answer 3

Write an integration test that tests the container's configuration by looping over all root types in the application and requesting them from the container/kernel. By requesting them from the container, you are sure that the container can build-up the complete object graph for you.

A root type is a type that is requested directly from the container. Most types won't be root types, but part of the object graph (since you should rarely call back into the container from within the application). When you test the creation of a root type, you will immediately test the creation of all dependencies of that root type, unless there are proxies, factories, or other mechanisms that might delay the construction process. Mechanisms that delay the construction process however, do point to other root objects. You should identify them and test their creation.

Prevent yourself from having one enormous test with a call to the container for each root type. Instead, load (if possible) all root types using reflection and iterate over them. By using some sort of convention over configuration approach, you save yourself from having to 1. change the test for each new root type, and 2. prevent an incomplete test when you forgot to add a test for a new root type.

Here is an example for ASP.NET MVC where your root types are controllers:

[TestMethod]
public void CompositionRoot_IntegrationTest()
{
    // Arrange
    CompositionRoot.Bootstrap();

    var mvcAssembly = typeof(HomeController).Assembly;

    var controllerTypes =
        from type in mvcAssembly.GetExportedTypes()
        where typeof(IController).IsAssignableFrom(type)
        where !type.IsAbstract
        where !type.IsGenericTypeDefinition
        where type.Name.EndsWith("Controller")
        select type;

    // Act
    foreach (var controllerType in controllerTypes)
    {
        CompositionRoot.GetInstance(controllerType);
    }
}

UPDATE

Sebastian Weber made an interesting comment to which I like to respond.

What about delayed object creation using container backed (Func) or container generated factories (like Castle's Typed Factory Facility)? You won't catch them with that kind of test. That would give you a false feeling of security.

My advice is about verifying all root types. Services that are created in a delayed fashion are in fact root types and they should therefore be tested explicitly. This does of course force you to monitor changes to your configuration closely, and add a test when you detect a new root type is added that can't be tested using the convention-over-configuration tests that you already have in place. This isn't bad, since nobody said that using DI and a DI container means that we may get careless all of a sudden. It takes discipline to create good software, whether you use DI or not.

Of course this approach will get pretty inconvenient when you have many registrations that do delayed creation. In that case there is probably something wrong with the design of your application, since the use of delayed creation should be the exception, not the norm. Another thing that might get you in trouble is when your container allows you to resolve unregistered Func<T> registrations, by mapping them to a () => container.GetInstance<T>() delegate. This sounds nice, but this forces you to look beyond the container registration to go look for root types, and makes it much easier to miss one. Since usage of delayed creation should be the exception, you're better off with explicit registration.

Also note that even if you can't test 100% of your configuration, this doesn't mean that this makes testing the configuration is useless. We can't automatically test 100% of our software and should take special care of that part of our software/configuration that can't be tested automatically. You can for instance add untestable parts to a manual test script, and test them by hand. Of course, the more you have to test by hand, the more can (and will) go wrong, so you should try to maximize the testability of your configuration (as you should do with all of your software). You will of course get a false sense of security when you don't know what your testing, but again, this holds for everything in our profession.