Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

Mocking frameworks are useful for creating mock objects that isolate the code under test from its surrounding software environment. Some mocking frameworks cannot mock non-virtual methods, so they require that you create an Interface for each class, if you don't want to make the methods virtual.

How do you distinguish those Interfaces from the "real" ones? That is, if you have a public API, do you name the interfaces that you intend your customer to use something else, or do you hide the testing Interfaces in a separate assembly or namespace?

As an aside, is it really necessary to create all those Interfaces? I don't like the idea of making all my methods virtual, but I really don't like the idea of creating that many interfaces just to make them accessible to a mocking framework.

share|improve this question

I don't.

Either the class is (effectively) sealed/final or it has an interface. I don't buy the whole internal classes are somehow above the law: abstraction exists to protect you from change, and your internal types are just as likely to change.

Basic structures (DTO's, tuples, and other usually sealed/final objects) are fine in my experience to just use as is in tests. They are effectively part of the public interface of your modules.

share|improve this answer
OK, wait a minute. Interfaces can exist for reasons beyond simply providing a testing trampoline. They can also be used to identify an API that can have multiple underlying implementations, and for other non-trivial reasons, as you are probably already well aware. I claim that those deserve special mention in an API, precisely because they are likely to be used by the customer (Mocks don't count as a different underlying implementation). Nobody in their right mind would include all those interfaces in their customer documentation. (Customer: What are these for?) – Robert Harvey May 30 '13 at 23:10
@RobertHarvey - I concur, and in general, interfaces will be likely used by the customer. But the question indicates they won't be, and I would argue that if internal only types are beefy enough (or lie on module boundaries enough) that you want to mock them, you'll inevitably want to vary underlying implementations - so might as well abstract that to an interface even if it's not customer facing. – Telastyn May 30 '13 at 23:50
How do you test your sealed classes if they don't have interfaces? – Robert Harvey Jun 17 '13 at 17:20
@RobertHarvey - I just use them directly. – Telastyn Jun 17 '13 at 20:04
Hm? How do you mock them if the methods are not virtual? – Robert Harvey Jun 17 '13 at 20:05

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

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