--- title: "Dependency Injection - Is it relevant beyond unit testing?" url: "https://osherove.com/blog/2008/1/18/dependency-injection-is-it-relevant-beyond-unit-testing.md" canonical: "https://osherove.com/blog/2008/1/18/dependency-injection-is-it-relevant-beyond-unit-testing.html" published: "2008-01-18T14:07:35" updated: "2008-01-18T14:07:35" tags: ["General Software Devel..."] author: "Roy Osherove" description: "\"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…" usage: "Licensed under CC BY 4.0 — reuse, quote and adapt with attribution (Roy Osherove, link to the original page)." license: "https://creativecommons.org/licenses/by/4.0/" --- # Dependency Injection - Is it relevant beyond unit testing? By Roy Osherove January 18, 2008 In [General Software Devel...](https://osherove.com/blog/category/general-software-devel) **Historical article** · Originally published January 18, 2008; technical details may be outdated. > "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](http://www.typemock.com/community/viewtopic.php?t=694) 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](http://theruntime.com/blogs/jacob/), 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](http://crazybob.org/2007/06/introduction-to-guice-video-redux.html) 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](http://theruntime.com/blogs/jacob/archive/2007/08/21/crazy-bob-is-my-hero.aspx). 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? ## Lessons on this topic - [Refactoring Hardcore Skills](https://courses.osherove.com/courses/legacy-code-hero/refactoring-hardcore-skills/) · Legacy Code Hero ## More in General Software Devel... [All posts in General Software Devel...](https://osherove.com/blog/category/general-software-devel) - Jan 22, 2008 ### [Computer Magic](https://osherove.com/blog/2008/1/22/computer-magic.html) - Jan 18, 2008 ### [Trying out Team City - Looks Promising!](https://osherove.com/blog/2008/1/18/trying-out-team-city-looks-promising.html) - Jan 17, 2008 ### [The evolution of Unit Testing Syntax and Semantics](https://osherove.com/blog/2008/1/17/the-evolution-of-unit-testing-syntax-and-semantics.html) - Jan 15, 2008 ### [BitDiffer, anyone?](https://osherove.com/blog/2008/1/15/bitdiffer-anyone.html) --- ## About the author **Roy Osherove**: Senior Solutions Architect at AWS working on AI for production and AI-driven development; author of The Art of Unit Testing and Elastic Leadership, with about 20 years of consulting and training on unit testing, TDD, team leadership and continuous delivery. ### Sites - [RobotPaper](https://robotpaper.ai/): This blog: AI patterns and anti-patterns, AI and coding agents, and engineering leadership. - [osherove.com](https://osherove.com): Roy's personal site. Author of The Art of Unit Testing and Elastic Leadership; consulting and training on unit testing, TDD, team leadership and continuous delivery, plus about 20 years of blog posts. - [The Art of Unit Testing](https://www.artofunittesting.com): The Art of Unit Testing, 3rd Edition (Manning): readable, maintainable, trustworthy unit tests, plus TDD workshops in C#, JavaScript, Java and Kotlin. - [5whys.com](https://www.5whys.com): Roy's writing on software team leadership: self-organizing teams, surviving chaos, learning mode and the Elastic Leadership model. - [Pipeline Driven](https://pipelinedriven.org): Continuous delivery and DevOps practices: build patterns, pipeline-friendly testing, DevOps metrics and enterprise DevOps. - [Elastic Leadership](https://www.elasticleadership.com): Elastic Leadership, Roy's framework for software team leaders (survival, learning and self-organizing modes). ### Social - X: https://x.com/royosherove - LinkedIn: https://www.linkedin.com/in/osherove/ ### Contact - Contact form: https://forms.gle/jQSx5KoXvrVA1JCK7 ### License Licensed under CC BY 4.0 — reuse, quote and adapt with attribution (Roy Osherove, link to the original page). License: https://creativecommons.org/licenses/by/4.0/