SpeakENG

Jeremy has always been a bit of a sceptic when it came to the AutoMockingContainer, and he's not alone, apparently hammett isn't a fan either (any explanation hammett?). I could never understand why he's sceptical, but it looks like he's starting to get a little more curious as he's including an AMC in StructureMap 2.5.

There are a few interesting things in his implementation. The most noticeable difference is that  he extends the MockRepository. This means you don't need two objects floating around, your MockRepository and your AutoMockingContainer, you just combine them. The biggest issue I see with that is you can't do things like this with HubServices:

_container.AddService(_container.Create<HubService>());
MyClass foo = _container.Create<MyClass>();

I do this all the time when I use hub services, since it is much easier to just use the real implementation of HubService as all it does is expose its child services as properties and those are the things I really want to mock.

I should also reiterate the benefits of using an AMC friendly test fixture that has instance helper methods for Create, Get, AddService, etc, and now I'm seeing people offload things like mocks.Record and mocks.Playback; I like this too.  The "mocks.ClassUnderTest" is definitely too verbose for me.

The other big question I have to ask is... why have a StructureMap AMC? Why not just use the existing one? Yes, it uses Windsor behind the scenes, but that doesn't matter does it? If you're worried about your test dependencies I suppose it does, but are you? Don't get me wrong, I'd jump ship in a heartbeat to the StructureMap AMC if it was proven faster as a result of using StructureMap instead of Windsor, but I think that's about the only reason, since most features could easily be added to keep in parity. Especially now that the AMC has been so well maintained since it's a part of RhinoTools now.

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... ;)

Generally when I'm testing something that has dependencies my test fixture looks something like this:

  [TestFixture]
  public class FooTests
  {
    private MockRepository _mocks;
    private Foo _foo;
    private IBar _bar;

    [SetUp]
    public void Setup()
    {
      _mocks = new MockRepository();
      _bar = _mocks.DynamicMock<IBar>();
      _foo = new Foo(_bar);
    }

    [Test]
    public void Test()
    {
      using (_mocks.Unordered())
      {
        SetupResult.For(_bar.ProvideService()).Returns(1);
      }
      _mocks.ReplayAll();

      Assert.IsTrue(_foo.DoSomething());
      _mocks.VerifyAll();
    }
  }

Granted, I'm starting to use our AutoMocking Container more and more, but that's not the point of this post. As an aside, Ayende has some more examples on its usage and has added it to Rhino.Tools.

Anyways, back to the subject at hand. The above works great if nothing really happens in your Foo constructor. But what happens if part of the constructor is to call a method on IBar? Well surely you could just move the construction to the Test method:

    [Test]
    public void Test()
    {
      using (_mocks.Unordered())
      {
        _bar.DoSomeSetup();
        SetupResult.For(_bar.ProvideService()).Returns(1);
      }
      _mocks.ReplayAll();
      _foo = new FooTests(_bar);

      Assert.IsTrue(_foo.DoSomething());
      _mocks.VerifyAll();
    }

That works, but what if you have more than one test? Well, you could just do the same thing in every test, but that's an annoying amount of repeated code that doesn't add any value. You can't simply Extract Method on it because you'll most likely need to setup other expectations for other scenarios you're testing. So... now I do this:

    [Test]
    public void Test()
    {
      SetupMocks(delegate()
      {
        SetupResult.For(_bar.ProvideService()).Returns(1);
      });

      Assert.IsTrue(_foo.DoSomething());
      _mocks.VerifyAll();
    }

    public void SetupMocks(Block block)
    {
      using (_mocks.Unordered())
      {
        _bar.DoSomeSetup();
        if (block != null) block();
      }
      _mocks.ReplayAll();
      _foo = new FooTests(_bar);
      
    }

And this:

public delegate void Block();

Funny what a little Ruby exposure will do to you...

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

Jeremy has always been a bit of a sceptic when it came to the AutoMockingContainer, and he's not alone, apparently hammett isn't a fan either (any explanation hammett?). I could never understand why he's sceptical, but it looks like he's starting to get a little more curious as he's including an AMC in StructureMap 2.5.

There are a few interesting things in his implementation. The most noticeable difference is that  he extends the MockRepository. This means you don't need two objects floating around, your MockRepository and your AutoMockingContainer, you just combine them. The biggest issue I see with that is you can't do things like this with HubServices:

_container.AddService(_container.Create<HubService>());
MyClass foo = _container.Create<MyClass>();

I do this all the time when I use hub services, since it is much easier to just use the real implementation of HubService as all it does is expose its child services as properties and those are the things I really want to mock.

I should also reiterate the benefits of using an AMC friendly test fixture that has instance helper methods for Create, Get, AddService, etc, and now I'm seeing people offload things like mocks.Record and mocks.Playback; I like this too.  The "mocks.ClassUnderTest" is definitely too verbose for me.

The other big question I have to ask is... why have a StructureMap AMC? Why not just use the existing one? Yes, it uses Windsor behind the scenes, but that doesn't matter does it? If you're worried about your test dependencies I suppose it does, but are you? Don't get me wrong, I'd jump ship in a heartbeat to the StructureMap AMC if it was proven faster as a result of using StructureMap instead of Windsor, but I think that's about the only reason, since most features could easily be added to keep in parity. Especially now that the AMC has been so well maintained since it's a part of RhinoTools now.

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... ;)

Generally when I'm testing something that has dependencies my test fixture looks something like this:

  [TestFixture]
  public class FooTests
  {
    private MockRepository _mocks;
    private Foo _foo;
    private IBar _bar;

    [SetUp]
    public void Setup()
    {
      _mocks = new MockRepository();
      _bar = _mocks.DynamicMock<IBar>();
      _foo = new Foo(_bar);
    }

    [Test]
    public void Test()
    {
      using (_mocks.Unordered())
      {
        SetupResult.For(_bar.ProvideService()).Returns(1);
      }
      _mocks.ReplayAll();

      Assert.IsTrue(_foo.DoSomething());
      _mocks.VerifyAll();
    }
  }

Granted, I'm starting to use our AutoMocking Container more and more, but that's not the point of this post. As an aside, Ayende has some more examples on its usage and has added it to Rhino.Tools.

Anyways, back to the subject at hand. The above works great if nothing really happens in your Foo constructor. But what happens if part of the constructor is to call a method on IBar? Well surely you could just move the construction to the Test method:

    [Test]
    public void Test()
    {
      using (_mocks.Unordered())
      {
        _bar.DoSomeSetup();
        SetupResult.For(_bar.ProvideService()).Returns(1);
      }
      _mocks.ReplayAll();
      _foo = new FooTests(_bar);

      Assert.IsTrue(_foo.DoSomething());
      _mocks.VerifyAll();
    }

That works, but what if you have more than one test? Well, you could just do the same thing in every test, but that's an annoying amount of repeated code that doesn't add any value. You can't simply Extract Method on it because you'll most likely need to setup other expectations for other scenarios you're testing. So... now I do this:

    [Test]
    public void Test()
    {
      SetupMocks(delegate()
      {
        SetupResult.For(_bar.ProvideService()).Returns(1);
      });

      Assert.IsTrue(_foo.DoSomething());
      _mocks.VerifyAll();
    }

    public void SetupMocks(Block block)
    {
      using (_mocks.Unordered())
      {
        _bar.DoSomeSetup();
        if (block != null) block();
      }
      _mocks.ReplayAll();
      _foo = new FooTests(_bar);
      
    }

And this:

public delegate void Block();

Funny what a little Ruby exposure will do to you...

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

Jeremy has always been a bit of a sceptic when it came to the AutoMockingContainer, and he's not alone, apparently hammett isn't a fan either (any explanation hammett?). I could never understand why he's sceptical, but it looks like he's starting to get a little more curious as he's including an AMC in StructureMap 2.5.

There are a few interesting things in his implementation. The most noticeable difference is that  he extends the MockRepository. This means you don't need two objects floating around, your MockRepository and your AutoMockingContainer, you just combine them. The biggest issue I see with that is you can't do things like this with HubServices:

_container.AddService(_container.Create<HubService>());
MyClass foo = _container.Create<MyClass>();

I do this all the time when I use hub services, since it is much easier to just use the real implementation of HubService as all it does is expose its child services as properties and those are the things I really want to mock.

I should also reiterate the benefits of using an AMC friendly test fixture that has instance helper methods for Create, Get, AddService, etc, and now I'm seeing people offload things like mocks.Record and mocks.Playback; I like this too.  The "mocks.ClassUnderTest" is definitely too verbose for me.

The other big question I have to ask is... why have a StructureMap AMC? Why not just use the existing one? Yes, it uses Windsor behind the scenes, but that doesn't matter does it? If you're worried about your test dependencies I suppose it does, but are you? Don't get me wrong, I'd jump ship in a heartbeat to the StructureMap AMC if it was proven faster as a result of using StructureMap instead of Windsor, but I think that's about the only reason, since most features could easily be added to keep in parity. Especially now that the AMC has been so well maintained since it's a part of RhinoTools now.

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... ;)

Generally when I'm testing something that has dependencies my test fixture looks something like this:

  [TestFixture]
  public class FooTests
  {
    private MockRepository _mocks;
    private Foo _foo;
    private IBar _bar;

    [SetUp]
    public void Setup()
    {
      _mocks = new MockRepository();
      _bar = _mocks.DynamicMock<IBar>();
      _foo = new Foo(_bar);
    }

    [Test]
    public void Test()
    {
      using (_mocks.Unordered())
      {
        SetupResult.For(_bar.ProvideService()).Returns(1);
      }
      _mocks.ReplayAll();

      Assert.IsTrue(_foo.DoSomething());
      _mocks.VerifyAll();
    }
  }

Granted, I'm starting to use our AutoMocking Container more and more, but that's not the point of this post. As an aside, Ayende has some more examples on its usage and has added it to Rhino.Tools.

Anyways, back to the subject at hand. The above works great if nothing really happens in your Foo constructor. But what happens if part of the constructor is to call a method on IBar? Well surely you could just move the construction to the Test method:

    [Test]
    public void Test()
    {
      using (_mocks.Unordered())
      {
        _bar.DoSomeSetup();
        SetupResult.For(_bar.ProvideService()).Returns(1);
      }
      _mocks.ReplayAll();
      _foo = new FooTests(_bar);

      Assert.IsTrue(_foo.DoSomething());
      _mocks.VerifyAll();
    }

That works, but what if you have more than one test? Well, you could just do the same thing in every test, but that's an annoying amount of repeated code that doesn't add any value. You can't simply Extract Method on it because you'll most likely need to setup other expectations for other scenarios you're testing. So... now I do this:

    [Test]
    public void Test()
    {
      SetupMocks(delegate()
      {
        SetupResult.For(_bar.ProvideService()).Returns(1);
      });

      Assert.IsTrue(_foo.DoSomething());
      _mocks.VerifyAll();
    }

    public void SetupMocks(Block block)
    {
      using (_mocks.Unordered())
      {
        _bar.DoSomeSetup();
        if (block != null) block();
      }
      _mocks.ReplayAll();
      _foo = new FooTests(_bar);
      
    }

And this:

public delegate void Block();

Funny what a little Ruby exposure will do to you...

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