Friction in Settingup test using abstract classes rather than Interfaces

Question

I have started following Test Driven Development and find it very logical and helps me a lot.

I have one question

1) In lot of StackOverflow answers I have seen that people say abstract base class adds lot of friction to setup a test. If we use interfaces, there would be less friction. What I am thinking is, if there is no default implementation in Abstract classes how does this make any difference in setting up the test.

For Eg : HttpContext ... it exposes lot of properties which needs to be setup (read queryString,FormCollection etc). Here you have to mock all these things before you can actually use the HttpContext in a unit test. (I prefer using moq)

If someone can help me understand why this adds more friction, it would be helpful.

--RN

Answer 1

Some languages don't have a defined Interface type, such as C++. There, interfaces are constructed via a class definition containing only pure virtual member functions, a virtual destructor and no member variables.

The issues associated with abstract classes is that sometimes you want/need to mock up a method which is defined within the abstract class. In C++ there exists the very real possibility that a function is not labled virtual and within another object's member functions are accessed via a pointer object to the parent definition. Such a situation poses enormous difficulties in separating functionality between objects being tested.

This is, of course, coming from a C++ perspective. I'd yeild to another in a different language.

Answer 2

I can only think of one relevant difference with respect to unit testing (if we're ruling out default implementations): an abstract classes' methods may be sealed,^* in which case they cannot be mocked, while interfaces never have this problem.

^* Or final, or not declared virtual in the first place depending on the language.