Development Blog

 Thursday, February 22, 2007
« Our CodeGenerator in CastleContrib! | Main | Object Oriented Design, Testability and ... »

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:

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:

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:

public void DoWork_Always_AsksOtherServices()
  using (_mocks.Unordered())

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:


  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.


  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

Friday, February 23, 2007 7:26:49 AM (Pacific Standard Time, UTC-08:00)
I think that totally rocks!!! Has it worked with generic services? I would assume so since they work fine with the IoC anyway :)
Friday, February 23, 2007 7:36:39 AM (Pacific Standard Time, UTC-08:00)
It seems to me that if you need an IoC container to create all mocks for a class, then the class probably relies upon too many services and does too many things. Though I'm saying that without knowing the concrete use case, of course.
Sergey Koshcheyev
Friday, February 23, 2007 7:53:35 AM (Pacific Standard Time, UTC-08:00)
I don't think this is about services for a single class, but the pattern of injecting interfaces and creating mocks in every test... We use a base test class so we can call CreateMock<T> instead of _mocks.CreateMock<T>. This not only removes the need for CreateMock, but it also removes the injecting constructor code. So once again, that totally rocks!
Wednesday, May 30, 2007 11:10:49 AM (Pacific Standard Time, UTC-08:00)
How come this facility has not been added to the castle codebase, do you know?
Wednesday, May 30, 2007 12:00:34 PM (Pacific Standard Time, UTC-08:00)
It requires Rhino.Mocks, which castle does not currently have a dependency on... we haven't really pushed adding it to the codebase as we still don't even use it here, heh.
Aaron Jensen
Wednesday, June 13, 2007 6:06:51 AM (Pacific Standard Time, UTC-08:00)
Very, very interesting!
Wednesday, June 13, 2007 11:56:42 PM (Pacific Standard Time, UTC-08:00)
An interesting idea, does it not worry you that your unit tests are now depending on a DI framework (even if indirectly)?
Thursday, June 14, 2007 5:49:24 AM (Pacific Standard Time, UTC-08:00)
Not really... I don't see how its any different than depending on a unit testing framework or a mock object framework.
Aaron Jensen
Comments are closed.