What is the benefit of mocking an interface instead of a concrete class

Question

Is there a benefit in mocking a concrete class vs an interface?

sample:

In my CustomerService class I call the CustomerDataProvider like

customerDataProvider.GetCustomers();

customerDataProvider could also be of type ICustomerDataProvider. When I want to test the logic inside the CustomerService only without going to the database then I have to mock the customerDataProvider object of type ICustomerDataProvider OR CustomerDataProvider.

Where is the advantage in mocking one type over the other?

It kind of depends on why you need to mock it in the first place... could you describe your test scenario in a little more detail? Without it this is a subjective question. — Cᴏʀʏ, Jan 25 '12 at 21:08

Matt Mills · Accepted Answer · 2012-01-26T14:47:07.243

0

The primary benefit to mocking an interface rather than a class is that it's simpler - interfaces can't be sealed/final, they can't have methods you can't override, and they can't have unusual construction semantics. Mocking libraries can take away a lot of the headaches of mocking classes, but they can't make up for untestable design.

The primary reason to mock classes instead of interfaces is: sometimes you only have a class. If you're doing your own design and implementation then you can make the choice to build one or the other. If you're consuming someone else's library, you have to deal with what it provides.

edited Jan 26 '12 at 14:47

answered Jan 26 '12 at 01:40

Matt Mills

8,692
6
40
64

"...you have to deal with what it provides" a class always exists an interface not. So no benefit? – Pascal Jan 26 '12 at 07:57
Definitely benefits from an implementation point of view. Edited. – Matt Mills Jan 26 '12 at 19:10

What is the benefit of mocking an interface instead of a concrete class

1 Answers1