Jeremy has always been a bit of a sceptic when it came to the AutoMockingContainer, and he's not alone, apparently hammett isn't a fan either (any explanation hammett?). I could never understand why he's sceptical, but it looks like he's starting to get a little more curious as he's including an AMC in StructureMap 2.5.
There are a few interesting things in his implementation. The most noticeable difference is that he extends the MockRepository. This means you don't need two objects floating around, your MockRepository and your AutoMockingContainer, you just combine them. The biggest issue I see with that is you can't do things like this with HubServices:
_container.AddService(_container.Create<HubService>());
MyClass foo = _container.Create<MyClass>();
I do this all the time when I use hub services, since it is much easier to just use the real implementation of HubService as all it does is expose its child services as properties and those are the things I really want to mock.
I should also reiterate the benefits of using an AMC friendly test fixture that has instance helper methods for Create, Get, AddService, etc, and now I'm seeing people offload things like mocks.Record and mocks.Playback; I like this too. The "mocks.ClassUnderTest" is definitely too verbose for me.
The other big question I have to ask is... why have a StructureMap AMC? Why not just use the existing one? Yes, it uses Windsor behind the scenes, but that doesn't matter does it? If you're worried about your test dependencies I suppose it does, but are you? Don't get me wrong, I'd jump ship in a heartbeat to the StructureMap AMC if it was proven faster as a result of using StructureMap instead of Windsor, but I think that's about the only reason, since most features could easily be added to keep in parity. Especially now that the AMC has been so well maintained since it's a part of RhinoTools now.