[mcmire]

The problem with dependency injection in this manner is that your test code is using a fake class that's injected while your production code is using a real class.

This is fine if all you want to do is unit test your classes. That's beside the point though -- I would posit if you're bolting dependency injection onto your interfaces just to make your tests faster, you're not doing it right. Instead, bring that dependency injection into the forefront: to the constructor. Yes, this means to make an object, you'll have to make another object first, both in your production and test code. But now your interface acts the same way in both places. If this sounds very Java-like, well... maybe Java got it right. (There was an article on the Twitter blog in the early days about this but I can't remember where it is now...)

Of course, this is going to introduce complexity and now you have to decide whether that complexity is worth it.