SpeakENG

I haven't posted in a while and decided to write a post about one of the little side projects I've worked on recently. I've been lurking around on the ALT.NET mailing list and one of the discussions I take time to keep up on is on Dependency Injection. Something I worked on a few weeks ago has some applications in that area and so I decided to see what others thought.

I was talking with Aaron several months ago about how many problems constructors in static languages cause. Ruby people are fortunate in that their constructors are much more flexible than their C# counterparts. Want something to be a singleton? Just return the same instance from the constructor! Lifecycle management and dependencies can be the responsibility of the constructor itself, rather than a function of a container.

Over the weekend a few weeks ago I wrote a library and MsBuild task that factors constructor calls out of code and into a pluggable factory system. You write code like this:

public class EmailSender
{
  public void TellEveryone(string message)
  {
    TemplateRenderer renderer = new TemplateRenderer();
    Console.WriteLine(renderer.Render(message));
  }
}
public class EmailSenderFactory : IObjectFactory<EmailSender>
{
  public EmailSender Create()
  {
    return new EmailSender();
  } 
}
EmailSender emailer = new EmailSender();
emailer.TellEveryone("Hello, World!");

What the MsBuild task will do is this:

1. Load the target Assemblies using Mono.Cecil
2. Find implementations of IObjectFactory<T> and add them to the FactoryMap.
3. Find all instances of new T() for each of those factories and replace them with a call to the Factories.Create<T>(), ignoring calls inside of factories themselves.
4. Weave the FactoryMap (just the Factory Type and its Object Type) into the Assembly.

So during runtime we can use the FactoryMap that was serialized in step #4 to create the factories and use them to create instances as they're demanded. It is important to note that your objects need default constructors, even though they may never be called after the code is weaved. One can also replace the factory implementations with IoC backed versions, etc...

Why don't you just create a New.Instance<T> method and use that instead of new T() and save yourself the pain of weaving and having a task and all that, moron?

Good question! I mostly did this as an exercise in code weaving using Cecil. It's a great library, although testing code using it can be a little tedious. I'm tossing around some other projects that I'd love to give a shot and this was a good introduction. You could achieve the same thing using reflection to build your factory map and remember to use New.Instance<T>() instead of the new operator in your code. Granted, the manual approach plasters the concern all over the place and weaving keeps the original code free from that. Which may be an OK trade-off for the simplified process.

Another thing to consider, is that perhaps the weaving approach has its applications elsewhere? Use it specifically for creating domain classes to transparently provide domain services? Another idea I've been tossing around is if you're writing code for platforms where garbage collection isn't as performant (xbox for example) you may be able to transparently add object pooling and other patterns after the fact and not clutter up the original code.

I want to release the code anyway, but I'm tired of uploading zip files. All my future source releases will probably be via Google Code or some public svn repository. Stay tuned.... In the meantime, feel free to opine.

There's a good back and forth going on about something I've been thinking about for quite a while. Jacob Proffitt is basically claiming that DI's primary benefit is mockability in unit tests and that we should all but ditch it in favor of using TypeMock to mock our tests. Meanwhile, Ayende and Nate Kohari have been defending DI with reasons like "getting low coupling between our objects" (Ayende) and "simply put, dependency injection makes your code easier to change" (Nate).

Well, I think I'm just going to have to agree with both of them... to an extent. I agree that DI promotes loose coupling, but I disagree that TypeMock is too powerful (even though I said just that in our podcast with Hanselman, I'm allowed to change my mind). I think that DI has its place, and is not a Silver Bullet. There have been a number of times when I was refactoring a class, pulling out a method object, or moving something to a a sub service (in my attempts to adhere to the Single Responsibility Principle) that I've questioned whether or not that new class warrants all of the following:

1. Having an interface.
2. Being added to the container and being injected.
3. Writing new tests for just that, even though tests were already passing and will continue to pass for its parent object with the same coverage %.
4. Being mocked out of the original tests.

The problem with doing #4 with a framework like Rhino Mocks is that it requires you to do #3 (obviously) as well as #1 & #2 . You can't mock unless your methods are virtual or you're interfaced and that mock is injected. With TypeMock I can do #3 and #4 without worrying about adding my new class to the container. So why not add it to the container? Well, because a great deal of the time You Aren't Gonna Need It. I think once one other class takes a dependency on that service you have enough justification to control its creation in one place by adding it to the container. However, a great deal of the time, these one off objects you create to increase readability and maintainability in your code just end up either changing the way you test your objects in that you're testing more than one class at a time, or you end up with an interface and constructor argument explosion solely so that you can mock them in tests. In situations like that, Jacob is right--the only real benefit is mockability. Maybe we should consider using something like TypeMock in these situations? Just because something is powerful doesn't mean its evil. We just need to exercise more caution and use it only in times its warranted.

That said, I've never actually used TypeMock and this is all purely conjecture based on what I've read about it. I just think that we can learn something from the Ruby guys and from people with the viewpoints of Eli and Jacob, as long as everyone realizes that neither sides of the camp is producing Silver Bullets.

Jacob posted about the AutoMockingContainer several months ago. At that time we didn't really use it, it was just kind of an implementation of an idea. Well, we've finally started using it in some side projects (Resharper.TestDrive for example), and I must say... wow. It is most definitely the way to instantiate your subject under test most of the time. Why?

1. It decouples your tests from your constructors. This means that if you have multiple TestFixtures for a class and you want to add a new service to your constructor, you don't have to change a thing in your tests.
2. It simplifies your tests. Things are just cleaner when you're not having to create all your mock services to inject into your subject under test.
3. It helps reinforce good mock usage. The default mock strategy is dynamic mocks. You can override that if you want to, but most tests should (in my opinion) be written with dynamic mocks. Like Dave talks about you only really want to set actual expectations on zero or one mock at a time. Everything else should be more stub-like.

I've started to use a base class for all my tests. Let's take a look at ReSharper.TestDrive's test base class:

  public abstract class AutoMockingTests 
  {
    private MockRepository _mocks;
    private AutoMockingContainer _container;

    protected MockRepository Mocks
    {
      get { return _mocks; }
    }

    protected AutoMockingContainer Container
    {
      get { return _container; }
    }

    [SetUp]
    public void BaseSetup()
    {
      _mocks = new MockRepository();
      _container = new AutoMockingContainer(_mocks);
      _container.Initialize();
      Setup();
    }

    public abstract void Setup();

    public T Create<T>()
    {
      return _container.Create<T>();
    }

    public T Mock<T>() where T : class
    {
      return _container.Get<T>();
    }

    public void Provide<TService, TImplementation>()
    {
      _container.AddComponent(typeof(TImplementation).FullName, typeof(TService), typeof(TImplementation));
    }

    public void Provide<TService>(object instance)
    {
      _container.Kernel.AddComponentInstance(instance.GetType().FullName, typeof(TService), instance);
    }
  }

So what's a test look like with this base class? Let's borrow Dave's example.

  public class SearchPresenterTests : AutoMockingTests
  {
    private SearchPresenter _presenter;
    private SearchResultDTO _fakeResults;

    public override void Setup()
    {
      this._fakeResults = new SearchResultDTO();
      this._presenter = Create<SearchPresenter>();
    }

    [Test]
    public void Can_search_for_customers_by_number_of_orders()
    {
      using (_mocks.Record())
      {
        Expect
         .Call(Mock<ISearchService>().GetCustomersByOrderCount(42))
         .Return(this._fakeResults);
      }

      using (_mocks.Playback())
      {
        _presenter.SearchByOrderCount(42);
      }
    }

    [Test]
    public void Search_results_are_displayed_to_the_user()
    {
      using (_mocks.Record())
      {
        mockView.SearchResults = _fakeResults;
        SetupResult
         .For(Mock<ISearchService>().GetCustomersByOrderCount(42))
         .Return(_fakeResults);
      }

      using (_mocks.Playback())
      {
        presenter.SearchByOrderCount(42);
      }
    }
  }

Not bad eh? You can do some more complicated things too. Let's say all your presenters take a hub service called PresenterServices. Rather than mocking it and its child services and setting up expectations for each of the children you can just use the real one and do this:

      Provide<IPresenterService>(Create<PresenterService>());
      this._presenter = Create<SearchPresenter>();

Now you can refer to all your hub's child services with the Mock<T>() method.

Ok, so if you made it this far you probably want to check it out for yourself. Thanks to Ayende, the AMC it is now part of Rhino.Tools so you can check it out (svn co https://rhino-tools.svn.sourceforge.net/svnroot/rhino-tools/trunk rhino-tools)  and build it yourself or just grab the current trunk build with all the dependencies here. Hope Oren doesn't mind me building and linking this... ;)

I've been writing a lot of tests lately because our code coverage isn't up to where we'd like it. NCover+NCoverExplorer is a pretty awesome and while it does have its quirks it has been incredibly useful. A lot of my adventures in writing tests is creating tons of RhinoMocks so that I can pass them to constructors and that sort of thing. So I got a strange idea, and I'm not sure how I feel about it necessarily and figured I'd propose it to all of you out there and get your thoughts.

Basically, 99% of the time in a services unit test, all the interfaces passed to the service will be mocks, so we end up with lots of functions that look like this:

[SetUp]
public void Setup()
{
  _service1 = _mocks.CreateMock<IService1>();
  _service2 = _mocks.CreateMock<IService2>();
  _service3 = _mocks.CreateMock<IService3>();
  _serviceWeAreTesting = new DefaultServiceWeAreTesting(_service1, _service2, _service3);
}

If we do this a lot for DefaultServiceWeAreTesting, it's often refactored to a single location. All in all, it can be very repetitive to create all the mocks. So, as an experiment I decided to leverage the power of the IoC container, in our case Windsor, to take care of a lot of the mundane for me. In the end I end up with this code:

[SetUp]
public void Setup()
{
  _mocks = new MockRepository();
  _container = new AutoMockingContainer(_mocks);
  _service = _container.Create<DefaultServiceWeAreTesting>();
}

AutoMockingContainer is simply a WindsorContainer with a custom facility and dependency resolver that supplies a RhinoMock for any interface that is resolved. We've also moved the setup code into a base class AutoMockingTests that has the container and mock repository. We can then write code that uses the mocks from the container:

[Test]
public void DoWork_Always_AsksOtherServices()
{
  using (_mocks.Unordered())
  {
    _container.Get<Service1>().DoWork();
    _container.Get<Service2>().DoWork();
    _container.Get<Service3>().DoWork();
  }
  _mocks.ReplayAll();
  _service.DoWork();
  _mocks.VerifyAll();
}

Of course, you don't have to always do the Get call on the container, you can do that in the Setup and use member variables, etc... the point is, the mocked services are created for us. We can also mark other types so that they aren't tested, and take advantage of the IoC and injection that we use in our application to speed up writing and maintaining tests. The implementation I've uploaded allows you to associate a particular strategy with service dependencies. They are:

• StubbedStrategy: A mock will be created, then for each property a GetValue expectation (with Repeat.Any) will be added to return a value for that property. The value will be retrieved like any other dependency (it's strategy will be gotten, and the value from that)
• DynamicStrategy (default): A DynamicMock will be created for the dependency.
• StandardStrategy: A standard mock from CreateMock.
• NonMockedStrategy: Automatically set for any service that is registered normally with the container - a standard container resolve.

So, pros and cons? To get things started:

Pros

1. Can be easier to maintain and write tests. Adding a dependency or changing the constructor breaks tests in ways that the production environment can usually handle just fine.
2. Automatic testing the services construction via the IoC container.

Cons

1. Speed/peformance? Does making the container such an integral part of the test fixtures hurt performance? Setup has to be longer when we're creating the container the way we are. Does this matter? Only as long as the time saved when writing tests is larger than the time it takes to run them, which I'm sure is the case...

What do you think? So far we really like the idea, or at least think it's interesting. Here are the sources:

Source and Binaries

So I was recently at a good friend's birthday gig. He's actually my old lead at Microsoft. Anyways, some of our friends that are still at Microsoft were at the party and I got a chance to talk to one of them for a while about various things... primarily open source, TDD, Inversion of Control and Mock objects. He was interested in Rhino Mocks and wanted me to email him about it. Instead of just doing that I threw together a good sized email. Here it is (slightly modified):

Good to see you again. As we talked about, there has been quite a shift in the way we write programs... that is a shift towards a much more testable, more maintainable type of programming. I know there are teams at Microsoft that have embraced recent changes... some have gone agile, most use some form of continuous integration, and some have written Inversion of Control containers (the Composite UI Application Block by the patterns & practices group has a container in it), but I'm sure most teams aren't employing all of these practices and could benefit from at least some of them.

In a number of teams, I think that there are a lot of improvements that can be made... even without shipping anything that's open source.

Firstly, you should take another serious look at Test Driven Development. I've attached an interesting study on TDD, and you may want to skim the MS Press book on the subject.

Also, the following blogs have some real good info on it:
Jeremy D. Miller's TDD Posts
Ayende's TDD Posts

A big part of TDD and Unit Testing in general is being able to remove not only your ephemeral dependencies, but also the rest of your dependencies. That way you know, when something fails, exactly what class caused the failure... it's the class being tested. In order to get rid of the dependencies, you need to replace them. In order to replace them, you need two things. The first is a replacement. The second is a method in which to inject the replacement. Mocks and stubs can handle the first task. I mentioned that we use Rhino Mocks:

Ayende's Rhino Mocks Posts

The library is great, it makes for very readable code and it's pretty darn flexible.

The second item can be a bit more complicated. The thing you usually see when class Foo depends on class Bar is this:

class Foo 
{
  private Bar _bar = new Bar(); 

  public string DoStuff()
  {
    return _bar.DoSomeOtherStuff() ? "yes" : "no"
  }
} 

Now if you're going to test Foo, you'll also be testing Bar. You can't avoid that the way it's written. Now, it's good to test Foo talking to Bar eventually, but that's what integration tests are for... not Unit tests. So what do you do? This:

interface IBar { bool DoSomeOtherStuff(); } 

class Foo
{
  private IBar _bar;
  public Foo(IBar bar) { _bar = bar; } 

  public string DoStuff()
  {
    return _bar.DoSomeOtherStuff() ? "yes" : "no"
  }
} 

Subtle difference, but this allows you to throw any implementation of IBar (including a mock) into Foo. That allows you to write a test like this:

[Test]
void DoStuff_WhenBarReturnsTrue_ReturnsYes()
{
  MockRepository mocks = new MockRepository();
  IBar bar = mocks.CreateMock<IBar>();
  Foo foo = new Foo(bar);
  Expect.Call(bar.DoSomeOtherStuff()).Returns(true);
  mocks.ReplayAll(); 

  Assert.Equals("yes", foo.DoStuff());
} 

Now even if Bar changes, or Bar doesn't even exist, this test will still pass.

Here's the definition from Martin Fowler of Dependency Injection/Inversion of Control

Unfortunately, real programs are a lot more complicated than just one class depending on another... dependency chains are generally pretty deep, and one class can depend on 5 classes, each of which depends on 2, each of which has a different lifetime... per web request, transient, singleton, etc. It would be quite a pain if you had to instantiate everything like this:
Foo foo = new Foo(new Bar(new Blah(), Yadda.Instance));

Fortunately, it's not terribly complicated to write a Container that can handle all of this for you... so all you do is something like:
Foo foo = container.Resolve<Foo>();

There are several:

• The CAB contains one
• Castle Windsor
• Spring.NET

And then I went on to mention how long this mail was getting and that I was going to post it to this blog.