Jeremy Miller tweeted earlier in the week about the dangers of using an auto mocking container and how it can encourage sloppy design:

I haven’t used an auto mocking container but it seems to me that although that type of tool might be useful for reducing the amount of code we have to write in our tests it also hides the actual problem that we have - an object has too many dependencies.

By hiding the creation of stubs/mocks for those dependencies in our test we are addressing the effect and not the cause i.e. we are bear shaving.

Jeremy followed this up with a couple of quite insightful comments:

Another somewhat related situation where I’ve noticed a similar problem is when we have several tests which require a certain method to be stubbed out and in the interests of reducing duplication we pull that up into a setup method.

While this achieves that goal it also means that there is information that is hidden away from us when we read each of our tests.

One approach that I’ve seen encouraged is that we should never use a setup method so that we have to create everything we need for our test in the test body.

I quite like this approach because it encourages us to see any problems that we’re creating with respect to writing difficult to test code but quite often what ends up happening is we’ll copy and paste tests because there’s more code to write for each test.

I’m coming to the conclusion that there’s no one approach that will stop us making design mistakes and that as Jeremy says, we need to make sure that we pay attention to what we’re doing.