jimmy keen

on .NET, C# and unit testing

How to mock private method ...

April 25, 2012 | tags: unit-testing mocking c#

Ever attempted to mock any of the following:

What all those points have in common? They share similar problem - you cannot do that. Why is that so? To explain why such limitation is present on all of the most popular mocking frameworks, first we need to understand how exactly they work.

Under the hood

Luckily, this isn’t too complicated. What your mocking framework does when you call A.Fake<IUserRepository>() or new Mock<IUserRepository>() is creation of new type, a type that will implement IUserRepository interface (or derive from mocked base class). Naturally, it doesn’t create any new source files, compile code and magically “put” new types into your assembly. Instead, mocking framework creates new, dynamic assembly (generated at runtime) and creates new type implementing your interface (also generated in runtime) which resides in the generated assembly. Mock is essentially an instance of dynamically generated type implementing your custom interface that comes from dynamically generated assembly:

Mock = dynamic type from dynamic assembly implementing your interface with some smart tracking/setup mechanisms addition

By “dynamic” we understand “generated at runtime”, rather than having anything to do with C# 4 dynamic types feature.

The dynamic type generating library used by Moq, FakeItEasy and RhinoMocks is called Castle Dynamic Proxy. The name might sound familiar to those who ever had to mock internal types – in order to make internals visible to isolation framework you actually have to make them visible to DynamicProxyGenAssembly2. This is the assembly where castle’s proxy types are being stored (as briefly explained here).

Where is my private mocking?

Some bells should be ringing by now. If mock is simply derived class, how could it possibly access private method from base class let alone intercept/override it? It can’t and that’s where the story ends. Note that such problems are non-existing when dealing with interfaces simply because interfaces cannot declare any private members1. The problem also expands on more concepts related to inheritance. Can you override static method? No. There you go, no mocking. What about extension method? Again, same story. Extension method is a static method with some extra treatment from compiler2.

There’s one more thing related to mocking classes - class member cannot be mocked unless it’s marked with virtual keyword. This should be obvious by now, as in order to track mocked member, mocking frameworks need to derive from class in question and “insert” their own tools instead of member’s original body.

Let’s recap

At this point we should know which parts of class cannot be mocked. Mocking interfaces is trivial and causes no problems. For classes, general rule is simple:

Cannot override = cannot mock

This essentially leaves out:

Is this the definite end? What should we do when we just have to mock (or test) one of those things? I address those questions in my next blog post, How to mock private method – solutions.

  1. This is actually restricted by CLR: it requires all interface members to be public and C# compiler simply makes them public for you

  2. Special ExtensionAttribute is applied to a method and persisted in compiled module’s metadata