"What do you do if you've spent all this time convincing the powers that be that DI is absolutely essential and now . . . it isn't? That's going to hurt. Much better to just dismiss TypeMock as "too powerful" and move on. "
This is a quote from Jacob Proffitt's post on our forum regarding typemock and design for testability. I urge you to register and comment there if this is interesting to you.
The more I read Jacob's blog, and his (sometimes controversial) thoughts on Dependency injection and good design, the more I like it. He really makes me think and challenge assumptions I've held dear for a long time.
For example, is Dependency Injection really necessary when you can write tests against your code without it? Does good design necessarily involve DI? More specifically, do you need DI all over the place, or just in specific places where you know dependencies could be a problem? (I'd recommend viewing this video BTW)
I can see how DI is useful when you have different teams working on something you depend on, in which case you'd have to have a delayed implementation decision (where the actual implementation of an interface is gotten at runtime), but this can be achieved though a regular factory as well. In this interesting post, Jacob has a matrix of possible Design decisions regarding DI. Read it.
I'm going to go read more of his posts. BTW, Jacob seems to be pro-Typemock to a degree, and that raises good questions as to why.
As for the title of this post, yes I do believe DI is relevant beyond unit testing, but it is not the ultimate truth in design just as singletons may have their place, or inheritance has its place.
Will we throw the baby out with the bath water?
The .net world as a whole has been doing great moving towards a world of better design, better practices and more. DI is a relatively new concept in the .NET world for most people (who didn't' come from Java).
In that light, it almost scares me to try and dismiss DI or design for testability simply because of all the other good things this thinking represents.
Perhaps people aren't ready to say "yes, we know DI exists, but we know where we don't necessarily need it", because they don't know enough in this world.
perhaps bringing DI and testability concepts is good, if for no other reason than to teach people what decoupling really means, with "testing" being just the excuse to make it happen.
We have put so much effort in making testing and testability drive lots of good design decisions, that, if "unit testing" didn't catch on in the .net world, we'd have a hard time introducing them.
Perhaps (being devils advocate) it is too early to dismiss this thinking, or to drive holes in it, for fear of throwing the baby out with the bath water.
What do you think?