Combining Unit Tests (mocking) and a Dependecy Injection Framework [duplicate]

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.

Answer 2

You are getting some things confused.

Implementation 3 is better then number 2, because you don't need to setup the DI framework in your unit tests.

So when testing number 3 you would do:

ITransportation transportationMock = MockRepository.GenerateStricktMock<ITransportation>();

// setup exceptations on your mock

var person = new Person(transportationMock);

The DI framework is something that's only needed when constructing object trees in production code. In your test code you have total control of what you want to test. When Unit Testing a class, you mock out all dependencies.

If you also want to do some integration testing you would pass a real Bike to your person class and test it.

The idea of testing classes in total isolation is that you can control each and every code path. You can make the dependency return correct or incorrect values or you can even have it throw an exception. If everything is working and you have a nice code coverage just from your unit tests, you will only need a couple of bigger tests to make sure that your DI is wired correctly.

The key to writing testable code is to split object creation from business logic.

Answer 3

My 2 cents...

Although point 2 is an example of the Dependency Inversion Principle (DIP), it uses the Service Location Pattern, rather than Dependency Injection.

Your point 3 Illustrates Dependency Injection, where the IoC container would inject the dependency (ITransportation) into the constructor during build up of Person.

In your real app AND the unit test, you would want to use the IoC container to build Person as well (i.e. don't new Person directly). Either use the service locator pattern (kernel.Get<Person>(); ), or DI (e.g. Setter) if your Unit Test Framework supports this.

This would then Build Up Person AND its Dependencies (viz the Configured concrete class for ITransportation) and Inject that into Person as well (obviously, in the unit test your IoC would be configured for the mocked / stubbed ITransportation)

Finally, it is the Dependencies that you would want to Mock, i.e. ITransportation, so that you can test the Transport() method of Person.

Since Bike has no dependencies, it can be Unit Tested directly / independently (You don't need a mock to test Bike.Ride() unless a dependency is added to Bike).