Question

Possible Duplicate:
Using IoC for Unit Testing

I think I do have a Problem understanding the way Unit Tests and/or Dependency Injection are working. I’m using NUnit and Rhino Mocks for Unit testing and Ninject as an Dependency Incection Framework. In general, I though those two would fit perfeclty – but somehow, it seems like it gets just more complicated and harder to understand.

(I’ll try to make up a good example, to keep it clean and easy. It’s about me, riding a bike).

1.) Without DI / Unit Tests:
Without knowing of DI and Unit Tests, my code would have looked like that – and I’d be happy:

public class Person
{
    public void Travel()
    {
        Bike bike = new Bike();
        bike.Ride();
    }
}

public class Bike
{
    public void Ride()
    {
        Console.WriteLine("Riding a Bike");
    }
}

To ride my bike i would just need: new Person().Travel();

2.) With DI:
I don’t want that tight coupling, so I need an Interface and a NinjectModule! I’d have some Overhead, but that will be fine, as long as the code is easy to read and understand. I’ll just pass the code for the modified Person class, the Bike class is unchanged:

public class Person
{
    IKernel kernel = new StandardKernel(new TransportationModule());
    public void Travel()
    {
        ITransportation transportation = kernel.Get<ITransportation>();
        transportation.Ride();
    }
}

I could still ride my bike with just: new Person().Travel();

3.) Considering Unit-Testing (without DI):
To be able to check if the Ride-Method is called properly, I’ll need a Mock. As far as I know, there are gernerally two ways to inject an Interface: Constructor Injection and Setter Injection. I choose Constructor Injection for my example:

public class Person
{
    ITransportation transportation;

    public person(ITransportation transportation)
    {
        this.transportation = transportation;
    }

    public void Travel()
    {
        transportation.Ride();
    }
}

This time, i would neet to pass the bike: new Person(new Bike()).Travel();

4.) With DI and preparing for Unit-Tests
The class in 3. Considering Unit-Testing (without DI) would do the job without modification, but I would need to call new Person(kernel.Get<ITransportation>());. Through that, it feels like I’m loosing the benefit from DI – the Person class could call Travel without any coupling and any need to know what kind of class the transportation is. Also, I think this form is lacking a lot of the readability of example 2.

Is this how it is done? Or are there other – more elegant ways achieving Dependency Injection and the possibility to unit test (and mock)?

(Looking back, it seems the example is really bad – everyone should know what kind of transportation device he is riding at the moment…)

Answer 1

Generally I try to avoid using a IoC container for my unit testing – just use mocks and stubs to pass in the dependencies.

Your problem starts in scenario 2: This is not DI – this is the service locator (anti-)pattern. For real Dependency Injection you need to pass in your dependencies, preferably via constructor injection.

Scenario 3 is looking good, this is DI and generally also how you are enabled to test your classes in isolation – pass in the dependencies you need. I rarely find the need to use a full DI container for unit testing since each class under test only will have a few dependencies, each of which can either be stubbed or mocked to perform the test.

I even would argue that if you need a IoC container, your tests are probably not fine-grained enough or you have too many dependencies. In the later case some refactoring might be in order to form aggregate classes from two or more of the dependencies you are using (only if there is any semantic connection of course). This will eventually drop the number of dependencies to a level that you are comfortable with. That maximum number is different for each person, I personally strive to have 4 at most, at least I can count them on one hand and mocking is not too much of a burden.

A last and crucial argument against using an IoC container in unit testing is behavioral testing: How can you be sure the class under test behaves the way you want it to if you are not in full control of your dependencies?

Arguably you can achieve this by stubbing out all dependencies with types that set flags for certain actions, but this is a big effort. It is much, much easier to use a mocking framework like RhinoMocks or Moq to verify that certain methods were called with the arguments you specify. For that you need to mock the dependencies you want to verify calls on, an IoC container cannot help you here.