That would be work as well.

How about using Java’s Powermock/Easymock classextension (which is part of the core since v3)/or alike to mock a drive method on a Car, wich gives the same flexibility of having that indermediary interface just to restrict which method can be called.

Thanks for the comment, I do see your point and the way you suggest makes sense.
I think it is a perfectly reasonable conclusion. We both can probably agree that interface abuse is bad and is prevalent today. Which is the real problem that must be tackled. Thanks for the insights.

public class Car:IDrivable
{
public void Drive(){Console.WriteLine(“Vroom!Beep!”);};
public decimal Fuel{get;set;}
public void OpenBoot(); //and many other badly designed methods/properties, etc.
}

public interface IDrivable
{
void Drive();
}

….all we’re doing here is using the language conttructs available to us in C# to declare to a consumer “look, the only thing I can guarantee about that IDrivable Car I gave you is that it has a Drive() method.” – i.e the “Contract” aspect of an interface.
Now if there were some way to take your concrete implementation of Car and specify the contract inline on the actual class members , then that’d be just fine – but pointless unless you absolutely only ever needed a single concrete implementation of that behaviour, because otherwise you would need some way to share this definition of contract in a central place…bringing you right back to the interface keyword!

Also I would disagree that using interfaces for Unit testing is in some way an artificial and unnatural thing – in fact it’s more natural to me if I have a class “GroceryShopper” and I want to test that it goes to the store and buys milk given a means of transport:
Surely a properly isolated unit test says “Drive that IDrivable thing I gave you to the store and get some milk” because we really only care about the milk, not the vehicle, as opposed to “Drive this Car to the store…” where we are now relying on having a working and callable Drive method that won’t throw, etc…and even if you use a stub Car object, how do you guarantee that the stub’s Drive method won’t drift in signature from the concrete’s method without some kind of…contract…to enforce it, thus rendering your tests meaningless unless you test objects by contract only.

Just my 2c 🙂

Thanks great comment. I agree about integration testing. Typemock is very nice, works like magic! 🙂

I not am not real fan of unit testing since I develop data-base oriented applications. I just never seen a need there, but I have found integration testing to be useful. Apparently, typemock is a framework that allows you to test dependencies without using the standard dependency injection techniques. Here is a link that discusses this: http://www.infoq.com/news/2007/12/does-di-pay-off

Ruling our interfaces completely is equally wrong as ruling out unit testing or dependency injection for that matter. All three have their strengths and bad spots if used in a wrong way. They all need to be balanced to achieve SOLID. It is not very difficult to come up with example to support any argument in the world of programming.

Yes, there is certainly still a place for unit testing, but much of the unit testing I see today with heavy dependency injection and mocking really doesn’t test much at all.

Are you serious about moving away from unit testing? Unit testing are most useful because quick feedback loop. Integration/Acceptance tests do not give you quick and pin-pointed feedback. I would rather review every usage of interface and make sure interfaces are not abused instead of abandoning unit testing altogether.