That whole "Auto Mocking Containers encourage sloppy design" meme that I blew off last week? Seeing an example in our code.
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.
You know though, I still think it comes down to you being responsible for paying attention.
It's no different than still having to worry about DB optimization even though the ORM is shielding you from the details
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.