--- title: "Pros and Cons and of using an Auto Mocking container in your tests" url: "https://osherove.com/blog/2008/4/25/pros-and-cons-and-of-using-an-auto-mocking-container-in-your.md" canonical: "https://osherove.com/blog/2008/4/25/pros-and-cons-and-of-using-an-auto-mocking-container-in-your.html" published: "2008-04-25T08:54:18" updated: "2008-04-25T08:54:18" tags: ["Agile", "Art Of Unit Testing", "Testing Guidelines", "Unit Testing"] author: "Roy Osherove" description: "In regards to my post about injecting mocks and stubs using a container in your tests, Dave asks in the comments: Why would you want to do this in the first place? Here are the things I can think about right now (pros…" 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/" --- # Pros and Cons and of using an Auto Mocking container in your tests By Roy Osherove April 25, 2008 In [Agile](https://osherove.com/blog/category/agile), [Art Of Unit Testing](https://osherove.com/blog/category/art-of-unit-testing), [Testing Guidelines](https://osherove.com/blog/category/testing-guidelines), [Unit Testing](https://osherove.com/blog/category/unit-testing) **Historical article** · Originally published April 25, 2008; technical details may be outdated. In regards [to my post about injecting mocks and stubs using a container](http://weblogs.asp.net/rosherove/archive/2008/04/24/injecting-typemock-stubs-and-mocks-using-the-structuremap-container-in-a-unit-test.aspx) in your tests, Dave asks in the comments: Why would you want to do this in the first place? Here are the things I can think about right now (pros and cons). I'd love to hear your thoughts. Pros for using a container in your tests: - Can lead to **easier test maintainability**. You can add new dependencies to object under test without worrying about existing tests that use that object, since those dependencies will usually be automatically stubbed out as part of the object creation process - Allows easier focus on testing interaction. When you have a class that has 3+ dependencies, you'd usually want to have no more than one mock against which you'll test the interaction of the class, while the rest would be stubs.  Since everything is getting stubbed by default, all you need to worry about when writing the test is about the mock's expected interaction and perhaps setting one of the stubs to run using a specific behavior.  In any case, writing the boilerplate stubbing code for **all** the dependencies is spared from you, something which I have struggled with before Cons of using a container: - It could make the **test a little less readable** in terms of understanding what gets injected and what the actual dependencies are. Assuming the reader already knows how to use containers, there is still a very clear separation between setting up the container's mocks and stubs and looks at where they are being used. By design , a container's work is hidden under an abstraction layer, which also makes the test reader not see how the mocks and stubs fit together inside the object under test. ## More in Agile [All posts in Agile](https://osherove.com/blog/category/agile) - May 10, 2008 ### [NullObject.For - As simple as it gets, but no simpler](https://osherove.com/blog/2008/5/10/nullobjectforlttgt-as-simple-as-it-gets-but-no-simpler.html) - Apr 30, 2008 ### [Unit Testing Denial Pattern #1: Pretending the test is no longer valid](https://osherove.com/blog/2008/4/30/unit-testing-denial-pattern-1-pretending-the-test-is-no-long.html) - Apr 14, 2008 ### [Creating a AutoMockingContainer with Microsoft Unity - Pretty darn simple.](https://osherove.com/blog/2008/4/14/creating-a-automockingcontainer-with-microsoft-unity-pretty.html) - Mar 15, 2008 ### [Belgium TechDays Slides and demos, and my travel schedule](https://osherove.com/blog/2008/3/15/belgium-techdays-slides-and-demos-and-my-travel-schedule.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/