So far I have used to write interfaces to those classes I want to mock/fake. Reason for that is that those classes don't have any virtual method to overwrite. But resently I have figured out that I could use virtual methods also.

When should I use virtual methods rather than interfaces?

Should I even make most of methods virtual to make faking easier in the future?

  • 7
    whats wrong with interfaces?
    – Ewan
    Jul 10 '17 at 8:12
  • 2
    One point where I thought virtual method could be better than interface is when I need to fake only one method and there isn't interface yet. Jul 10 '17 at 19:50
  • 1
    @Ewan They are a separate artifact that needs to be maintained in parallel with the class and using interfaces everywhere has the effect of obfuscating direct relationships between objects and increasing project file and line count significantly. They are also slow, which can make a huge difference for performance-sensitive areas (i.e. serializers, database engines, etc) where calls in tight loops could otherwise be inlined. Nov 28 '19 at 12:10

How would virtual methods help? The idea of mocking is that you rip out a class completely from your application and plug in a completely different mocked class, with the only thing in common that they both implement the same interface. Inheritance doesn't come into the game at all.

  • 1
    If I want to fake only one method. For example method that calls some web api. Jul 10 '17 at 19:47
  • 2
    @LassiAutio Why not create an interface with only that one method then, and have the class you are trying to mock implement it?
    – Eternal21
    Jul 11 '17 at 11:34
  • 5
    If you want to "fake" only one method and keep the rest of the methods, then that one method should probably go into a different class... Jul 11 '17 at 17:51
  • 2
    @TannerSwett: They can be in the same class - but it's probably relevant to separate it into a different interface and have the class implement both interfaces. This is classic ISP.
    – Flater
    Nov 22 '18 at 9:17

I favour making methods virtual over extracting an interface. The performance hit is negligible. In Java, where methods are virtual by default, people don't worry about this nearly as much.

I've seen far far too many codebases where every class has a corresponding interface in the same namespace. It makes the project confusing, as you don't know if an interface type is an abstraction or merely a testing artifact.

edit: It's also worth considering if you really need to make mocking possible - perhaps you can test via your applications public interface, i.e. outside-in testing.


I would not say that using virtual method for mocking is a bad idea. It is yet another tool for the job.

I'm comparing mocking via interface vs delegate vs virtual method in C# in this article. As you can see virtual method option looks attractive due to the smallest code changes for supporting mocking possibility, of course at the cost of trade-off.


Virtual methods and overriding them is not a good way to make mocks compared to interfaces.

Because you will have to reference the underlying class to create your mock. So your tests will be reliant on a reference to that particular library

And also because you will expose methods that you otherwise might not want to.


If youre needing to make your methods virtual in order to test them (i.e. youre expanding the public API of your class purely to accommodate your unit tests), then its a good sign that your class has too much work to do.

You can resolve this by refactoring your class, and moving the code your attempting to expose into its own unit, and injecting an instance of your new unit into the calling class.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.