# Automocking containers are not just for mocks

DevFeed: [Automocking containers are not just for mocks](<https://devfeed.tech/articles/automocking-containers-are-not-just-for-mocks-33366.md>)

Original publisher: [Read original article](<https://timkellogg.me/blog/2011/04/13/automocking-containers-are-not-just-for>)

Published: 2011-04-13T00:00:00Z

Content type: opinion

Language: en

Sources: [Tim Kellogg](<https://devfeed.tech/sources/tim-kellogg.md>)

Topics: [Testing](<https://devfeed.tech/topics/testing.md>), [unit tests](<https://devfeed.tech/topics/unit-tests.md>), [IoC (Disambiguation)](<https://devfeed.tech/topics/ioc.md>)

Tags: [component](<https://devfeed.tech/tags/component.md>), [implementation](<https://devfeed.tech/tags/implementation.md>), [integration-test](<https://devfeed.tech/tags/integration-test.md>), [testing](<https://devfeed.tech/tags/testing.md>), [unit-tests](<https://devfeed.tech/tags/unit-tests.md>)

## AI overview

The article argues that automocking containers can support partially mocked integration tests, not only unit tests using mocks. It describes MoqContrib's approach of favoring the last registered component, allowing tests to start with production implementations and replace selected components with mocks, or override mocks with production implementations.

## Source excerpt

In my last post I introduced MoqContrib's automocking container. In this post I want to describe what sets it apart from MoqContrib's previous automocking container and all other automocking containers that I've heard of thus far.A Castle.Windsor contributor said that for unit tests, "it's recommended that you don't use the container at all, or if the test setup gets too dense because of dependencies, use an AutoMockingContainer." This is in response to a stack overflow question regarding how to remove components in order to replace them with mocks. There are others that agree with him.I don't agree with Mauricio or Derek (from the links above). I strongly believe that there are several reasons to let an automocking container have real services registered that aren't mocks. The primary reason is for integration tests. This is where you are testing a system of modules, a subset of the entire system, but you still need to isolate those modules to just the system under test (SUT). So while the dependencies within the SUT are going to be implemented with real implementations, everything else is mocked. This is a partially mocked situation.One of the big reasons to use an automocking container is just to simplify everything. Sure, you're setups are starting to get pretty long for unit tests, but sometimes you run into issues where there is already a component registered so you can't register a mock without first removing the original component. This is very tedious and totally ruins any love you might have had for your IoC container.In MoqContrib 1.0 the container will favor the last component registered over everything else. This is handy because you can do setups by exception. For an integration test fixture you can setup everything as a production implementation and then just mock components as needed. You can also do it the other way and just override with production implementations. I believe this will lead to much cleaner tests and much less time tracking down "how