October 2005 - Posts

TypeMock.Net and mocking interfaces using Dynamic Mocking

TypeMock.Net is a mocking object framework with a difference - whereas NMock or Rhino.Mocks require you to follow a dependency injection pattern to allow a mocked object to be passed in during testing, TypeMock will allow you to intercept calls to mocked objects without having to pass in a reference to it directly.

The magic to make all this possible is achieved by monitoring your applications execution by interfacing to the .Net Framework profiler API. When the Common Language Runtime loads a method, TypeMock retrieves the MSIL for the method and replaces it with its own instrumented MSIL code.

The main benefit that I have seen so far has been that it is now possible to mock out 3rd party components which were probably never developed with test driven development in mind. I have successfully produced an integration test assembly which we run against each new version of the component we receive which verifies that it still behaves consistently - I can then produce unit tests against all my component client classes with a mocked out component which is very handy to avoid the very time consuming internal initialisation.

My next experiment with this product will involve mocking some of the Content Management Server 2002 and Sharepoint Portal Server 2003 classes to more effectively test custom placeholders,web parts and client classes which handle interacting with the respective APIs.

I have only found 1 major gripe with the product - it cannot create a dynamic mock object to mock any interface which contains a method with a rectangular array return type:

e.g.   double[,] CannotMockMethod();

To be fair to the TypeMock guys they have responded to my bug report very rapidly and are investigating the issue but this is also proving problematic with every other mocking framework I have tried to date including the very popular NMock and Rhino.Mocks.

I had an opportunity to investigate the issue within the source for NMock and I suspect that pretty much all the dynamic mocking frameworks out there are working in the same way to mock interfaces. The framework generates a type implementing the desired interface dynamically at runtime using the System.Reflection.Emit classes to emit the MSIL to achieve the task of mocking the method. The expected return value is passed by the framework to the evaluation stack and then requires to be popped from the evaluation stack to the frame stack. With value types this can be done directly since the value itself is stored on the evaluation stack but with reference types only the reference is actually stored on the stack so the type must be cast back to the frame stack by emitting using OpCodes.CastClass - which fails when attempting to do this on a rectangular array throwing a SystemTypeLoad exception. Unfortunately, I haven't figured out exactly why yet but I have discovered that rectangular arrays have to be handled differently in the MSIL and have getters and setters so maybe this could be the root of the problem? I will blog the solution if/when I get it sorted out....