Call Counting when unit testing

I’ve been trying out the free version of TypeMock solator (TMI) recently – basically does the same sort of thing as Rhino Mocks / Moq i.e. mocking of interfaces and virtual methods.

Although it’s undoubtedly not as common or popular as those two long-established free frameworks (yet), it has a very clean API, and thankfully opts to ignore arguments when validating calls by default, so you avoid the requirement in Moq to have silly amounts of It.IsAny<String>() for every argument etc. etc.

What is Call Counting?

One thing it doesn’t have though is the ability to mock a result for a number of calls, or to easily verify the number of times a method was called. Now, I’ve been told recently that unit testing the number of times that a method is called can be considered a code smell leading to fragile tests… hmmm. Yes and no.

Here’s a simple caching scenario where if you are to verify that your cache works properly you’ll need to do some form of call counting.


So all the MyServiceCache class does is take in the “real” service, and wrap the call to GetData with a simple caching mechanism, essentially a form of decoration (incidentally, this is essentially one of the ways that IoC containers perform interception on types).

Unit testing our Service Cache

How do we unit test this service cache class? Well, here is a simple test class and a setup: –


And now a couple of unit tests that prove that the first time we call the cache, it calls the underlying “real” service and returns whatever that returns: –


Call Counting with Type Mock Isolator

There’s an internal side-effect going on when we call GetData() though, which is that it stores a reference to the object the real service returned and will use it for subsequent calls. So how can we prove that? By proving that repeated calls to the decorator only call the “real” service once, and that we return the same object for repeated calls.

Unfortunately, TMI doesn’t have any inbuilt way to prove a method was called a certain number of times, but there’s a workaround: –


What I really would have liked for the first test above would simply have been to say something like this: –




Call counting can be a signal that your unit tests are testing too much or are brittle. However, for some scenarios it’s necessary (unless someone can suggest a way to avoid it in the scenario above?). It’d be nice if TypeMockIsolator had a more readable way of checking this – it’s sometimes (though not often) required, and Moq and Rhino both have it.

Nonetheless, as an aside from this, I’d recommend having a look at the free version of TMI – it’s still a clean, easy-to-use mocking framework with the added benefit that you can always upgrade to the full version if required.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s