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

Many people recommend that we should code against interfaces and avoid statics for testability.

Interfaces are not just for testability, they are sometimes a requirement. But sometimes we introduce new interfaces in application only for testability.

If type mocking frameworks help us to isolate dependent types, then why should we use interfaces just for the sake of testability? Also, why should we avoid static members?

share|improve this question
If you're writing Java, Mockito supports mocking of concrete classes, not just interfaces. – Mike Partridge Feb 29 '12 at 13:44
@MikePartridge And PowerMock supports mocking of statics, but I don't see either of these uses as a warranted design and implementation of unit tests on a green project. I use and love Mockito because of the usability and readability, but its concrete class mocking and PowerMock's static mocking should really only be used for introducing unit testing into legacy projects or third-party libraries and components that do not work well with mocking frameworks. – maple_shaft Feb 29 '12 at 14:46

You don't have to introduce new interface if you are 100% sure that the class you are mocking will not have polymorphous behavior in the future.

Say if you are mocking on a DatabaseHelper class which help you access data from SQL Server, and you are sure you(or your sucessor developers) definitely won't let it support any additional Database(MySql,Oracle,etc) in the future, you can mock the DatabaseHelper directly without introduce a new interface.

However, most of the time, you can't predict the future, so you'd better introduce an interface for future extension.

we don't use interface just for the sake of testability. It is the pursuing of testability that forces us to write extensible/maintainable code by introduce new interface.

Also, why should we avoid static members

Static members is global state variable in its essence . Code units that sharing/access global state are usually highly-coupled, which is a threat for maintainability, thread-safety, and isolated unit testing,etc.

share|improve this answer
"if you are 100% sure that the class you are mocking will not have polymorphous behavior in the future" - I would argue that as soon as you decide something must be mockable, it is polymorphic NOW. – pdr Feb 29 '12 at 13:32
+1. Any decent IDE can generate an interface from a class declaration. Find out how yours does it and use that feature accordingly. – back2dos Feb 29 '12 at 13:32
@pdr There are isolation frameworks like TypeMock Isolator that allow you mock on nonpolymorphic class. – TomCaps Feb 29 '12 at 14:32
@TomCaps: I'm aware of that. I still argue that doing so makes a class polymorphic, by definition, so an interface is appropriate. I would only use that functionality where I cannot control the class I'm mocking. – pdr Feb 29 '12 at 15:00

If type mocking frameworks help us to isolate dependent types, then why should we use interfaces just for the sake of testability? Also, why should we avoid static members?

I think you answered your own question here. Interfaces representing a testable component improve the testability of the component and by that measure alone it is preferrable to components with functionality or business logic that has static typing. Unwarranted statics and singletons are far more difficult for the majority of mocking frameworks to work with. This makes unit tests more complicated.

Besides the testability benefits, a component having an interface decreases coupling between components. Components are modular and cohesive. Component based design calls for the Interface as the contract between the defined behavior and the actor. This aspect of a component makes them more substitutable.

share|improve this answer

These times where they are only introduced for testability is incorrect.

As others have said, programming against an interface decreases coupling between components, and allows your code to be easily extendable in the future.

This in turn allows you to more easily test components in isolation.

While introducing an interface may give you slightly more work now, it is a good foundation for your software to be built on.

share|improve this answer

I typically don't create a new interface every time I mock something out. I honestly feel that it doesn't provide enough value and it's just one more file to manage. Once the application's business logic code drives me to multiple implementations I may extract an interface. I may also create an abstract class or use another delegation pattern to implement it. As was mentioned elsewhere, the extract interface refactoring is a simple keystroke away and it allows us to create that interface just in time.

As far as statics are concerned, they have a tendency to encourage global state, which can be problematic (Object oriented global variables are still global variables). Also, I often see them used as creation methods called from within their collaborators instead of using DIY making them difficult to fake.



share|improve this answer

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.