In my previous post, I discussed what I called the “core” mocking features of Typemock Isolator. In this post I want to talk more about the features it offers over and above those of Rhino Mocks and Moq.
Coming from a Rhino or Moq background, there are a number of methods in the Isolator API that were new to me, simply because Isolator offers features that the others do not. First off, in the examples and scenarios I discussed in Part 1 of my review, Isolator can apply them in a number of other ways to the conventional applications.
Setting Fake Behaviours
Firstly, these can be set on non-virtual methods; you do not have to make methods virtual just so that your mocking framework can fake them. In fact, these can even be set directly on live objects (rather than ones that were created via Fake.Instance<T>()); you don’t need to create a fake object at all! Even better, you can fake just the method calls that you want; the others will continue to call the “real” implementation. You can also set behaviour on static classes, methods and properties just as you would for instance types using the WhenCalled method.
A very nice feature is that you can set behaviours on a subset of types in mscorlib, such as DateTime.Now, and a few others; however, it’s not a massive list. You can achieve similar behaviour with Microsoft’s Moles, but that requires code generation and other bits and pieces, whereas with Typemock it’s the same as mocking a regular method or property.
Finally, you can even set behaviours on private methods or properties, albeit using strings rather than Actions to specify the method (which is fair enough).
As above – verification can be applied on (I believe) to faked statics, privates etc..
Swapping is a Typemock-specific feature. It allows you to do three things: –
Intercept future construction of objects in your production code and replace those objects with fakes – essentially, hook into the new keyword to say “when you next new up an object of type T, use this fake object instead”.
Swap all calls to both current and “future” instances of any objects of <T> and replace with a fake object of your choosing.
Swap all calls to a specific method from one object to another. The replacement object can be a completely different type; the only restriction is that the method signatures must match.
In the example above, the next time we new up DataAccessLayer, we’ll get back the fake version of it. With this ability to fake “future” instances of objects, you can get around the requirement to use both interfaces and dependency injection techniques to mock dependencies. Imagine the following code, which uses standard DI to inject the DAL into a service class.
We can simplify this class to just this, whilst still allowing us to fake out the DAL: –
When the Service class is instantiated, the call to create the DataAccessLayer will be intercepted by Isolator and replaced with the fake. Whilst we’re at it, we’ve also removed the need for any IoC container to resolve the IDataAccessLayer dependency.
Indeed, if you’re willing to make the DataAccessLayer public again (or at least internal and visible to the test project), we can completely do away with a Fake in the above example as follows: –
Here, we don’t even bother with a fake – the Service creates a “live”, real DataAccessLayer and at runtime of our test we simply override the LoadEmployees method to return some other data – this is extremely powerful.
Typemock offers features that neither Rhino or Moq can do, with the ability to fake methods on live objects, static methods, constructors, future objects and even some BCL classes. That power shouldn’t, of course, excuse you from proper abstractions where appropriate, and I’ll discuss this more later in my review.