Mocking objects - declare all methods as virtual or use interface?

Question

In .net, unlike in Java, methods are not virtual by default. In order to use most mock object frameworks, you either have to mark the methods that you want to use on your mock as virtual on the `real' object, or you have to have an interface that you can mock that the class under test will accept in lieu of the implementation.

It seems like bad form to go and mark every method as virtual, but it also seems like bad form to define an interface for every single class.

What is the best thing to do?

Answer 1

Who says that you mock object has to derive from the same class hierarchy?

It's much easier to create a simple standalone class that has the needed interface and create instances of that object.

You can even create a hierarchy of mock classes and use that for purpose of unit-testing.

Answer 2

If I have to choose between the two, I'd go with the interface thing. An interface is meant to define a contract, which is basically what a mock object is going to adhere to. Marking a method as virtual might have unanticipated side effects. It affects the design of the actual class being mocked. An interface merely defines method names and will have no effect on the real class.

Answer 3

The best thing is to use your head. Think about your scenario, if it makes more sense to use virtual then do that. If however an interface is better suited for your task then do that.

So really I see it as this in adding new functionality

• Inheritence: Use virtual methods.
• Composition: Use interfaces.

I'm sure there are a bunch of caveats to this. So just use your head and do what is easiest in your scenario.

Answer 4

My rule of thumb is to define the interface if I expect to have multiple implementations, either actual concrete application classes or a single application implementation and a fake implementation for unit testing. If I only expect a single implementation and the class doesn't need faking (most don't), then I'll go the virtual method route and refactor to an interface as needed.