• Simplify a complex method,
• Promote DRY, and
• Make testing easier

Here’s my Union-required contrived example:

interface IFoo { }
interface IFooRepository
{
    IEnumerable<IFoo> GetFoos();
}

class FooProcessor
{
    IFooRepository FooRepository { get; set; }
    public FooProcessor(IFooRepository fr)
    {
        this.FooRepository = fr;
    }

    public IEnumerable<IFoo> GetProcessedFoos()
    {
        foreach (var foo in this.FooRepository.GetFoos())
        {
            // Do some processing on foo
            // ...
            // ...

            yield return foo;
        }
    }
}

The inside of the loop in FooProcessor.GetProcessedFoos() might suit being extracted into a new method:

public IEnumerable<IFoo> GetProcessedFoos()
{
    foreach (var foo in this.FooRepository.GetFoos())
    {
        yield return this.GetProcessedFoo(foo);
    }
}

public IFoo GetProcessedFoo(IFoo foo)
{
    // Do some processing on foo
    // ...
    // ...
    return foo;
}

Now I can test the foo processing code without having to worry about setting up an IFooRepository mock just to pass in a single IFoo. Unfortunately the FooProcessor class still has the IFooRepository dependency, which I could work around by passing null to the constructor:

var fooProcessor = new FooProcessor(null);
// test fooProcessor.GetProcessedFoo(...)

But that isn’t very clear, and when there are lots of tests and dependencies things can get very, very silly. Extracting the method into a separate class can solve the problem:

public IEnumerable<IFoo> GetProcessedFoos()
{
    foreach (var foo in this.FooRepository.GetFoos())
    {
        yield return new GetProcessedFooMethod().Execute(foo);
    }
}

public class GetProcessedFooMethod
{
    public IFoo Execute(IFoo foo)
    {
        // Do some processing on foo
        // ...
        // ...
        return foo;
    }
}

Now the method can be tested directly without concerning FooProcessor‘s dependencies:

var getProcessedFooMethod = new FooProcessor.GetProcessedFooMethod();
// test via getProcessedFooMethod.Execute(foo)

I pretty quickly found an issue with this approach. Say I’m integration testing B.MethodToTest() in the following code:

interface IInterfaceForA
{
    string DoSomethingInA(string s);
}
class A
{
    [Inject]
    public ISomeInnerDependency SomeInnerDependency { get; set; }

    public string DoSomethingInA(string s)
    {
        this.SomeInnerDependency.DoBlah(s);
        // ...
    }
}

class B
{
    [Inject]
    public IInterfaceForA A { get; set; }

    public string MethodToTest(string s)
    {
        this.A.DoSomethingInA(s);
        // ...
    }
}

So class B has a dependency on IInterfaceForA (which Ninject will inject with an instance of A), and class A has a dependency on ISomeInnerDependency. Now say that the implementation of ISomeInnerDependency that gets injected hits a database that doesn’t exist during the test and dies. I’m testing B.MethodToTest() and its interaction with A.DoSomethingInA() but I don’t know beforehand of A‘s dependency on ISomeInnerDependency, so when I run tests I’ll get unexpected failures which will depend on how I’ve set up Ninject prior to the test:

• if the test setup for Ninject doesn’t inject ISomeInnerDependency at all, I’ll get NullReferenceExceptions
• if Ninject is injecting the production implementation of ISomeInnerDependency, any type of error at all from just about anywhere in ISomeInnerDependency‘s implementation’s call stack

Either way I’m getting errors from code that I didn’t even know about beforehand. I can resolve this by doing something like injecting a mock into A.SomeInnerDependency but there’s no way I could have known about the dependency before spelunking into the A class.

If the method I’m testing happens to have five dependencies, and some of those dependencies have more dependencies, my workflow devolves into: Compile, Run test, Watch fail, Sort through call stack, Find dependency, Figure out some way for Ninject to inject some harmless stub, Repeat for next nested dependency. I’m spending more time finding, stubbing, and injecting dependencies then I am writing tests and production code combined.

There is an argument that the code I’m testing is too complex and should be refactored. Fair enough, and my new code is much cleaner now that I’m thinking about testability now, but:

• This is an integration test
• The code base has three years worth of (my) beginner crap thrown in
• I should be able to inject dependencies to existing code to increase testability and increase my efficiency, not to have to struggle with the DI framework and seemingly random run-time errors
• There is one developer, and this is an in-house business application that services 15 staff and 300 clients. No resources, no time.
• An oversight meant that Ninject didn’t inject some dependencies that made it into production. Nasty.

In short, Ninject ended up causing more problems than it solved. Time to take the power back:

interface IInterfaceForA
{
    string DoSomethingInA(string s);
}
class A
{
    public ISomeInnerDependency SomeInnerDependency { get; set; }

    public A(ISomeInnerDependency someInnerDependency)
    {
        this.SomeInnerDependency = someInnerDependency;
    }

    public string DoSomethingInA(string s)
    {
        this.SomeInnerDependency.DoBlah(s);
        // ...
    }
}

class B
{
    public IInterfaceForA A { get; set; }

    public B(IInterfaceForA a)
    {
        this.A = a;
    }

    public string MethodToTest(string s)
    {
        this.A.DoSomethingInA(s);
        // ...
    }
}

I’ve done two things here. First I dropped Ninject. Then I added constructors to A and B so that the dependencies are explicit. To create an instance of B I now have to provide the dependencies up-front rather than configure them beforehand (and hope I’ve covered everything):

var b = new B(new A(new InnerDependencyMuchoDatabase("database configuration...")));

In the test for B.MethodToTest() I can just pass a stub to A:

var b = new B(new A(stubInnerDependency));

var breakfast = new
{
    Cereal = "High fibre",
    Coffee = "Latte",
    Bacon = "Crispy"
};

In the scope of the object’s declaration, accessing the properties of breakfast is as simple as breakfast.Cereal. However accessing the properties outside of that scope is not as simple. Say we have an object ben with a method Eat(object meal). Within ben.Eat() we can’t do something directly with meal.Coffee because Coffee isn’t known in ben.Eat()‘s scope.

Getting a property value using reflection is pretty basic but takes a couple of steps. There are much more advanced uses of reflection that allow access to hidden properties, fields and methods, but picking public properties is probably the easiest case. The following method returns the value of a public property of an object. This could be used on an anonymous object, or on any other class of object.

using System.Reflection;
...
object GetPropertyValue(object o, string propertyName)
{
    var prop = o.GetType().GetProperty(propertyName);
    if (prop == null) return null;
    return prop.GetValue(o, null);
}
...
var cereal = GetPropertyValue(breakfast, "Cereal");
Assert.That(cereal, Is.EqualTo("High fibre"));

prop is a PropertyInfo object that lets the value of a property be retrieved via reflection. The same method can be used to get a dictionary of [property name, value] from an anonymous object:

prop is a PropertyInfo object that lets the value of a property be retrieved via reflection. The same method can be used to get a dictionary of [property name, value] from an anonymous object:

IDictionary<string, object> ObjectToDictionary(object o)
{
    var dict = o.GetType().GetProperties().ToDictionary(
        prop => prop.Name, prop => prop.GetValue(o, null)
            );
    return dict;
}

This sets up a dictionary where the key is the name of the property, and the value is (ahem) the value of the property:

var breakfastDictionary = ObjectToDictionary(breakfast);
Assert.That(breakfastDictionary.Count, Is.EqualTo(3));
Assert.That(breakfastDictionary["Coffee"], Is.EqualTo("Latte"));

Using anonymous objects and reflection is a bit slower to execute than using strongly-typed objects, but once the methods are in place to access the properties, the savings in developer time can be great. Leaving more time for breakfast. Speaking of which, I’m late for work.

The extension method is declared in a static class:

public static class PimpMyStringExtension
{
    public static string Pimp(this string s)
    {
        return s + " is pimped out";
    }
}

Adding the this keyword to Pimp‘s string s argument is what indicates that Pimp is an extension method to the string class. The Pimp method can now be called against any string:

Assert.That("test".Pimp(), Is.EqualTo("test is pimped out"));

As long as the PimpMyStringExtension is accessible to the consuming code, the String gets the Pimp() method added. "test".Pimp() actually just calls the static method under the covers, which is actually still an option:

Assert.That(PimpMyStringExtension.Pimp("test"), Is.EqualTo("test is pimped out"));

Extra arguments can be added to the extension method as well:

 public static string Pimp(this string s, int i)
{
    return s + " has been pimped with " + i;
}
...
Assert.That("test".Pimp(7), Is.EqualTo("test has been pimped with 7"));

Originally the Ninject kernel binding was like this:

NinjectContainer.Kernel.Bind<IAdditionProvider>().To<AdditionProvider>();

That tells Ninject to create a new instance of AdditionProvider every time. To get it to use the same instance – in effect a singleton – I changed the binding to this:

NinjectContainer.Kernel.Bind<IAdditionProvider>().ToConstant(new AdditionProvider());

I expected to see a huge performance gain, and feel like an idiot. There was a bit of a gain:

That’s roughly 8 seconds (or 12%) less then the 1m5s taken the first time around. So there’s a good gain to be had using ToConstant() to avoid creating unnecessary instances of the injected class, but still nothing like the benefits of only directly using Ninject outside of the loop.

I separated out 30 or so repositories, set up a heap of fakes, hooked up a handful of tests, and jumped into implementing the latest feature. Everything went well in development, I deployed, and all was shiny. Then the trouble started.

First the users started complaining about speed. Some operations were taking 10-20 times as long to run as before. That was because of calls to Ninject happening whenever many objects were being created, and inside of loops. Then some older Winforms components turned out to crash in the designer. That was due to the Ninject kernel not being set up when the component is executed by the designer – the new dependency on Ninject was failing. Then I read an article by Bob Martin and several of his tweets on the subject where he talks about the dependency framework itself becoming a dependency. Got that right.

I decided to replace the direct dependency injection via Ninject with a factory. This way the factory is the only place with the dependency on Ninject, and has the option of returning a mock if there is Ninject isn’t configured (to deal with the designer issues). It also lets me inject the dependency only once and reuse the result.

I set up a simple test to see what effect moving the dependency injection out of the loop would have on the speed. The first consumer of the test is has the DI on construction:

class InjectionTester
{
    [Inject] public IAdditionProvider Adder { get; set; }
    public int DoAdd(int a, int b) { return Adder.Add(a, b); }
}
...
// test using injection in the loop
for (int i = 0; i < 1000; i++)
{
    for (int j = 0; j < 1000; j++)
    {
        var tester = NinjectContainer.Kernel.Get<InjectionTester>();
        tester.DoAdd(i, j);
    }
}

The second consumer of the test uses a factory to get the dependency:

class AdditionProviderFactory
{
    public static AdditionProviderFactory Instance = new AdditionProviderFactory();

    IAdditionProvider additionProvider;
    object additionProviderLock = new object();
    public IAdditionProvider AdditionProvider
    {
        get
        {
            lock (additionProviderLock)
            {
                additionProvider = additionProvider ?? NinjectContainer.Kernel.Get<IAdditionProvider>();
            }
            return additionProvider;
        }
    }
}
class FactoryTester
{
    IAdditionProvider Adder = AdditionProviderFactory.Instance.AdditionProvider;
    public int DoAdd(int a, int b) { return Adder.Add(a, b); }
}
...
// test using the factory
for (int i = 0; i < 1000; i++)
{
    for (int j = 0; j < 1000; j++)
    {
        var tester = new FactoryTester();
        tester.DoAdd(i, j);
    }
}

The results are pretty impressive (looping a million times):

Thinking about it now it’s pretty obvious that DI is going to be a bit expensive, but seriously, using a factory is over 200 times faster. That should keep em quiet.

I’m using Ninject 2 for dependency injection, NUnit 2.5.3 for unit testing, and Rhino Mocks 3.6 for mocking. NUnit has a mocking framework built in but it doesn’t use strong typing, which I think was causing problems with Ninject.

What I’m really showing here is an example of how to inject a dynamically declared mock instead of a concrete fake. The fact that it is in the context of a test is actually irrelevant, but using mocks and fakes are obviously important in testing to reduce the complexity of the test.

Initially I’m using the default ConcreteFoo implementation of IFoo in the test. This test fails as intended:

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;

using Ninject;
using NUnit.Framework;
using Rhino.Mocks;

namespace Trifecta
{
    public interface IFoo
    {
        string Name { get; }
    }
    public class ConcreteFoo : IFoo
    {
        public string Name { get { return "You don't want to see me"; } }
    }

    public class FooConsumer
    {
        [Inject] public IFoo Foo { get; set; }

        public FooConsumer() {}
    }

    [TestFixture]
    public class FooConsumerTestFixture
    {
        IKernel Kernel { get; set; }

        [SetUp]
        public void SetUp()
        {
            // This is the standard setup that will need to be overridden in the
            // test.
            Kernel = new StandardKernel();
            Kernel.Bind<IFoo>().To<ConcreteFoo>();
        }

        [Test]
        public void FooConsumerGetsTheFoo()
        {
            // This test depends on a specific behaviour in IFoo, but ConcreteFoo
            // is going disappoint right now.
            var fooConsumer = Kernel.Get<FooConsumer>();

            Assert.That(fooConsumer.Foo.Name, Is.EqualTo("The foo for you"));
        }
    }
}

Settting up and binding the mock is all done in the test method. The mock IFoo instance is created, and the functionality that the test requires is added. IFoo is then bound to a delegate which returns the mock instance. The binding has a condition that causes the mock binding to be used rather than the ConcreteFoo binding, this seems to be easier then setting up the kernel from scratch for the test (possibly I’m just missing how to rebind).

[Test]
public void FooConsumerGetsTheFoo()
{
		// Create a mock implementation of IFoo that has the behaviour the test requires
		var mocks = new MockRepository();
		var mockFoo = mocks.StrictMock<IFoo>();
		Expect.Call(mockFoo.Name).Return("The foo for you");
		mocks.ReplayAll();

		// Bind the mock when injecting IFoo into FooConsumer. This overrides the binding
		// created in SetUp()
		Kernel.Bind<IFoo>().ToMethod(context => mockFoo).WhenInjectedInto<FooConsumer>();

		// fooConsumer's Foo should now be the mock IFoo created above
		var fooConsumer = Kernel.Get<FooConsumer>();

		Assert.That(fooConsumer.Foo.Name, Is.EqualTo("The foo for you"));
}

The test should now pass.

public class MyClass<T> :
    BaseClass<T>, IMyInterface
    where T : ClassOfT
{...}

There are two concurrent versions for both .NET 1.1 and .NET 2 (which is very handy since I’m limited to .NET 1.1 at work). The only difference between the versions is apparently use of templates for collections.

There’s a CodeProject article that gives a pile of simple demo code, and the main site is a Wiki with what looks like plenty of documentation. The library is licensed under the LGPL license, which means that derivative works must be LGPLed, but as long as the library’s DLLs are dynamically linked they can be included in commercial software.