I needed to move to the latest moq, however we are using the automocking from moqcontrib.
The only change is MoqFactory -> MoqRepository. But the patch is attached anyway if it makes things easier for you.
As we're in the middle of working on it and there will be API changes
we'd love any feedback you have on the existing MoqContrib AutoMocking
Would it be sufficient for your needs if only the namespace changed?
... we could pretty easily match the current API with an obsoleted
class in the new MoqContrib.AutoMock.Autofac package.
Any other feedback is greatly welcome.
Is anybody using the MVC or Silverlight support in the current MoqContrib?
Have you seen that for example ninject has an automocking kernel for moq?
Thanks for the feedback. Tim and I certainly aren't done so things are
subject to change.
Tim and I haven't yet fully synced up but let me explain a bit where I
want to see things go:
* Provide a small and simple interface for the AutoMocking container,
say IAutoMock, that provides an interface mostly equivalent to the
* Make it possible for people to use their existing IoC container to
do any overrides that they may need BUT don't force them to know about
or deal with the underlying container if it's not important (which
ideally will always be the case).
* Make it possible to use the Common Service Locator as their IoC
container backend (which will limit, only slightly, the supported
Case I - User is an IoC container power user and has custom
registrations in the IoC container:
var container = /* users own IoC container */;
var autoMock = new AutoMock(new InstanceProvider(container));
//... uses automock container as expected
Case II - User doesn't care about IoC container & randomly chooses one
of the integrations:
var autoMock = new AutoMock(new InstanceProvider());
// uses automock container as expected
We might even be able to do assembly scanning and figure out what the
correct InstanceProvider is so they can create the AutoMock container
without needing to know about the underlying container-specific
InstanceProvider, in which case it would be as simple as `new
I don't mind making more of the IoC containers functionality available
to the power users, perhaps through an Explicit Interface
implementation that's IoC container specific, but I'd expect that the
user would just use their IoC container in that case... And, even more
importantly, this is for testing. It's likely a smell (or we messed up
the API) if they need to do something that requires thorough knowledge
of or direct access to the IoC container.
Does the above sound reasonable? Thoughts and feedback?
It *shouldn't* be used in any new code. That said, I'm using my IoC
container extensively to bring Legacy code under test. The tests in
place were mostly integration tests with large pieces of the actual
application being run and loaded. I'm now using my container to swap
out many of these at test time. In this case, an AutoMocking container
without full support for the IoC container is useless.
That said, all the new tests can easily use the AutoMocking container.
> Also, I wouldn't recommend doing assembly scanning, as this would probably
> make tests using the automocking container slow.
Good point. I don't know of any other way to Load the correct
InstanceProvider, but it doesn't bother me at all to require it be
passed into the automocking container.
BTW, thanks for your suggestions yesterday about constructor actions
An AutoMocking container is essentially a very simple IoC container
that does little more than allow a concrete object to be instantiated
with its dependencies satisfied through the injection of mocks. Of
these mocks, only *one* should be used for verification as the purpose
of the test is to verify the behavior between the concrete SUT and one
of its dependencies. The other mocks, though injected, will not be
used or will be used as stubs. Given that purpose, an Automocking
container can have a very small footprint and only need perform a couple
of basic operations.
I imagine some of the above is a little idealistic, but it sounds like
we're all agreed on the simple nature of an AutoMocking container.
I think it does, as long as the abstraction doesnt leak
/kzu from Android