Auto-mocking container pitfalls?

I’m taking a closer look at the auto-mocking container idea, specifically as we’re including it in the upcoming release of NBehave.  I’m a little wary of prolonged use, but wanted to get some feedback (it’s also on the ALT.NET message board).  Some pitfalls I thought of offhand were:

• Can allow dependencies to get out of hand
• Can hide a code smell where you have too many dependencies
• Forces a reliance on an IoC container for all creation, inside and outside of tests

Specifically the one I’m most worried about is making it too easy to add a bunch of dependencies and creating god-classes that have too much responsibility and coordinate too much.  If I hide that complication in a unit test, it might be perpetuating a bad design.

On the other hand, plenty of design patterns exist to help hide that problem, including creation methods, factory methods, factories and abstract factories.  But I’m thinking I might rather have those abstract away the “what and how” than “just too many dependencies”.

Finally, AMC could be another sharp tool in the toolbox.  It can cut you if you’re inexperienced, but sometimes it can make the job much easier.  Luckily, no mistake is ever more than an iteration’s length away from reversal.  I’m going to proceed carefully, mindful of the pitfalls I think I might land in.