GuesPost: Typemock Isolator – Much more than an Isolation framework
Note: Cross posted from IUpdateable from Eric Nelson.
This is the second guest post from Gil Zilberfeld who works at TypeMock and kindly agreed to do a couple of guest posts on Mocking . The first was an Introduction to Mocking.
Typemock Isolator – Much more than an Isolation framework
In my last post, I showed how to fake a dependency. But this involved doing a couple of things. First, it involved changing the original method. Then, I had to write wrappers (a real wrapper and the fake wrapper) and finally, I had to inject the fake object in the test. This is a lot of work, even for a very simplistic example. The solution for that is an isolation framework.
Isolation frameworks isolate the code from their dependencies, but they do it programmatically, and without hassle. What makes Typemock Isolator 2010 different than other frameworks (like Rhino Mocks and Moq) is that you don’t need to change the tested code just to test it.
Let’s look at the test we got last time – using a fake Message Queue to test that the message was called:
[TestMethod]
public void Send_StringMessage_MessageWasSent()
{
var fakeQueue = new FakeMessageQueue();
var server = new Server();
server.SendMessage(fakeQueue, "message");
Assert.IsTrue(fakeQueue.messageWasSent);
}
We’re actually doing two things in this test with our fakeMessageQueue object. The first is changing behavior – the SendMessage method does not call the original SendMessage method. The second is testing that the method was called. We do this by using a public field in the fake object.
We can accomplish the same things much easily with Typemock Isolator. Let’s go back to the original method, before we changed it:
public class Server
{
public void SendMessage(MessageQueue queue, object message)
{
queue.Send(message);
}
}
With Isolator, the test would look like this:
[TestMethod]
public void Send_StringMessage_VerifyMessageWasSent()
{
MessageQueue fakeQueue = Isolate.Fake.Instance<MessageQueue>();
var server = new Server();
server.SendMessage(fakeQueue, "message");
Isolate.Verify.WasCalledWithAnyArguments(() =>fakeQueue.Send(null));
}
As you can see, there are a couple of changes. The first is the Isolate.Fake.Instance statement. It creates a fake MessageQueue object. This is the original MessageQueue type; only method calls on it are ignored when they are called. So when the server calls the Send method on the fakeQueue it is ignored.
The other half of the equation is to verify that the method was called. Instead of planting a field to save the result, we use the Isolate.Verify API to test that the method was called. We don’t care about arguments sent to the method, so we put null in the argument, just to keep the compiler happy.
This is the basic stuff. What really separates Isolator from the rest is that Isolator can change and verify method calls on any method: Static and sealed classes (like the “untestable” SharePoint).
And it can change objects in mid-run. Let’s say my method under test looks like this:
public void SendMessage(object message)
{
MessageQueue queue = new MessageQueue(@".\myQueue");
queue.Send(message);
}
This time the MessageQueue is created inside the method under test! But Isolator can help here as well:
[TestMethod]
public void Send_StringMessage_VerifyMessageWasSent()
{
MessageQueue fakeQueue = Isolate.Fake.Instance<MessageQueue>();
Isolate.Swap.NextInstance<MessageQueue>().With(fakeQueue);
var server = new Server();
server.SendMessage("message");
Isolate.Verify.WasCalledWithAnyArguments(() =>fakeQueue.Send(null));
}
Notice the Swap.NextInstance call? It replaces the next time a MessageQueue is created. And that exactly happens inside the method under test.
Typemock Isolator has lots of other capabilities that make it easier to write tests– like recursive fakes (the ability to create a full object tree of fakes in a single line) and Intellitest, auto completion for testing statements.
But don’t take my word for it. Take Isolator for a ride – it’s about easy unit testing.
Gil Zilberfeld