MoqContrib Upgrade to latest Moq

42 views
Skip to first unread message

Naeem Khedarun

unread,
Mar 22, 2011, 8:14:36 AM3/22/11
to moq...@googlegroups.com

Hello all,

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.

Regards,

Nym

upgrade_to_moq_4.0.10827

Derek Greer

unread,
Apr 5, 2011, 3:49:55 PM4/5/11
to Moq Discussions
+1


Also, the Moq.Contrib NuGet package should declare Moq as a
dependency.
>  upgrade_to_moq_4.0.10827
> 546KViewDownload

Kaleb Pederson

unread,
Apr 5, 2011, 4:20:54 PM4/5/11
to moq...@googlegroups.com
Tim Kellogg and I are in the middle of revamping MoqContrib at the new
MoqContrib repository that Daniel (kzu) setup on CodePlex
(http://moqcontrib.codeplex.com/). We do intend support for NuGet. As
well as easier and broader support for different IoC Containers.

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
API.

Thanks.

--Kaleb

> --
> Post: moq...@googlegroups.com
> Unsubscribe: moqdisc-u...@googlegroups.com

Naeem Khedarun

unread,
Apr 5, 2011, 4:26:35 PM4/5/11
to moq...@googlegroups.com
It might be a good idea to do a release for the latest Moq without any API changes, and then release your new API afterwards...

Kaleb Pederson

unread,
Apr 5, 2011, 4:34:20 PM4/5/11
to moq...@googlegroups.com
Thanks for the feedback. The existing AutoMocker is tightly bound to
Autofac which we don't want to be tightly bound to.

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?

Thanks.

--Kaleb

Naeem Khedarun

unread,
Apr 5, 2011, 4:36:20 PM4/5/11
to moq...@googlegroups.com
That would be fab, much appreciated!

LOBOMINATOR

unread,
Apr 6, 2011, 12:41:34 AM4/6/11
to moq...@googlegroups.com
Hy

Have you seen that for example ninject has an automocking kernel for moq?

Daniel

Tim Kellogg

unread,
Apr 7, 2011, 1:19:25 AM4/7/11
to Moq Discussions
Naeem, Derek,

The new API is a thin layer over the container's (Castle, Autofac,
etc) API. The only deviation as of yet is the presence of .Mock<>()
methods. So if you use Castle with some sort of service locator, your
service locator can provide it with the auto-mocking container for
unit tests:


public class ServiceLocator {

public static IWindsorContainer Current { get; private set; }

// For testing convenience
public static IAutoMockContainer MockContainer {
get {
if (Current == null || !(Current is IAutoMockContainer))
throw new InvalidOperationException();
else
return (IAutoMockContainer)Current;
}
}

public static void UseCastle() {
Current = new WindsorContainer();
}

public static void UseMoq() {
Current = new AutoMockContainer();
}

}


Then you can use this in your tests like:

var mock = ServiceLocator.MockContainer.Mock<IService>();
// setups

var obj = ServiceLocator.Current.Resolve<IService>();
// do something with obj

var verify = ServiceLocator.MockContainer.Mock<IService>();
// verification

Derek Greer

unread,
Apr 7, 2011, 9:51:43 AM4/7/11
to moq...@googlegroups.com
Why would I want to do that?




--
Derek Greer
Email: dbg...@gmail.com

Tim Kellogg

unread,
Apr 7, 2011, 10:18:57 AM4/7/11
to moq...@googlegroups.com
Derek

I know you're looking for an Autofac implementation, so it seems strange that I would provide a Castle implementation, but I just thought I would introduce you to the new API. My point being that the new API is going to feel just like your regular IoC container (in your case, Autofac) but with some minor tweaks. I would assume that this would be delightful to hear, since most people choose an IoC container because they like the API.

If you're questioning why you would want to use a service locator, the answer is you don't have to. When using an IoC container you either pass around a container everywhere, or you create a central access point (service locator). My particular example of a service locator is lame, there are several features I left out. Here's an article that Martin Fowler wrote that talks about using a service locator:


I'm not sure if that answers your question

Regards,
Tim Kellogg

Derek Greer

unread,
Apr 7, 2011, 11:30:51 AM4/7/11
to moq...@googlegroups.com
What lead you to believe I was looking for an Autofac implementation?

While an automocking container and an IoC container may share a few common characteristics, they have different purposes and I don't see a need to have a common interface.  I don't particularly care which IoC container an automocking library may choose to leverage, but I question whether it would need the baggage a typical IoC container brings at all.


Derek

Daniel Cazzulino

unread,
Apr 7, 2011, 11:35:17 AM4/7/11
to moq...@googlegroups.com, Tim Kellogg
If your production code is going out to find a container, you've failed to apply IoC.

/kzu

--
Daniel Cazzulino | Developer Lead | XML MVP | Clarius Consulting | +1 425.329.3471

Derek Greer

unread,
Apr 7, 2011, 12:02:47 PM4/7/11
to moq...@googlegroups.com
Agreed.  If you're passing around a container throughout your application then you're doing it wrong :)

Kaleb Pederson

unread,
Apr 7, 2011, 12:19:00 PM4/7/11
to moq...@googlegroups.com
Derek,

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
current one
* 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
operations).

For example:

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
AutoMock()`.

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?

Thanks.

--Kaleb

Derek Greer

unread,
Apr 7, 2011, 12:50:55 PM4/7/11
to moq...@googlegroups.com
I guess I'm not seeing where the underlying IoC features would be used in a typical unit testing scenario.  The only feature I see that would be a nice to have is constructor selection with primitive parameter values supplied.  What are some of the specific use cases where someone would be using advanced IoC features for mocking?

Also, I wouldn't recommend doing assembly scanning, as this would probably make tests using the automocking container slow.

Kaleb Pederson

unread,
Apr 7, 2011, 1:35:02 PM4/7/11
to moq...@googlegroups.com
On Thu, Apr 7, 2011 at 9:50 AM, Derek Greer <dbg...@gmail.com> wrote:
> I guess I'm not seeing where the underlying IoC features would be used in a
> typical unit testing scenario.  The only feature I see that would be a nice
> to have is constructor selection with primitive parameter values supplied.
>  What are some of the specific use cases where someone would be using
> advanced IoC features for mocking?

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
and initialization.

Tim Kellogg

unread,
Apr 8, 2011, 10:03:40 AM4/8/11
to moq...@googlegroups.com
Derek,

Can you explain what you use an auto-mocking container for? I was under the impression that auto-mocking containers are and are inseparable from inversion of control containers.

Tim Kellogg

Derek Greer

unread,
Apr 8, 2011, 2:48:48 PM4/8/11
to moq...@googlegroups.com
I consider auto-mocking containers to be a specialized, light-weight class of dependency injection containers which are minimally concerned with the creation of System Under Test components with test doubles supplied for the required dependencies.  While the needs of an auto-mocking container can be facilitated by a full-fledged IoC container coupled with mocking capabilities, much of the functionality provided by an IoC container is unneeded within the context of a test.  For example, tests are typically not concerned with the construction of full object graphs.  While some containers may provide this capability, the need for this behavior is a design smell which may point to Law of Demeter violations.  Other features of an IoC container which an auto-mocking container would have little use for is dependency lifetime management (e.g. singleton, transient, request scope, thread scope, etc.), context-specific setup (e.g. nested containers, scoping), named instances, static factory construction, auto-registration, open generic registration, aspect-oriented facilities, etc.  Basically, an auto-mocking container needs about 1/10 of the capabilities (perhaps much less?) of a modern IoC container such as StructureMap, Windsor, NInject, Autofac, etc.  The context of their use is also different in that they participate in a specification model as opposed to runtime initialization for production code.  This results in the need to approach the API design from a different perspective.


Derek

Daniel Cazzulino

unread,
Apr 8, 2011, 3:34:19 PM4/8/11
to moq...@googlegroups.com, Derek Greer
Agreed. Simpler API, way less surface needed for automocking. It's just like dynamic proxies are hidded behind Moq. You don't need to even care about the internal mechanism.

On a side note: http://kzu.to/lawofdemeter  


/kzu

--
Daniel Cazzulino | Developer Lead | XML MVP | Clarius Consulting | +1 425.329.3471


Kaleb Pederson

unread,
Apr 8, 2011, 3:44:36 PM4/8/11
to moq...@googlegroups.com
And here's part of my response to Tim in a private e-mail:

--
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.

--Kaleb

Daniel Cazzulino

unread,
Apr 8, 2011, 3:49:15 PM4/8/11
to moq...@googlegroups.com, Kaleb Pederson
I'd argue that the injected dependencies are also needed in order to perform additional setups if you need to verify interaction with them.

Precisely the reason why I prefer to use Mock.Of<IDep1>(), Mock.Of<IDep2>(), etc., as I can easily switch to keeping the mock or adding some additional behavior with just a lambda, i.e. Mock.Of<IDep1>(x => x.SaveChanges() == 1)

;)

/kzu

--
Daniel Cazzulino | Developer Lead | XML MVP | Clarius Consulting | +1 425.329.3471


Tim Kellogg

unread,
Apr 8, 2011, 11:56:53 PM4/8/11
to moq...@googlegroups.com
So given all these responses, why doesn't a thin layer on top of a full IoC container fulfill this? It lets you keep all your production code unmodified and it would be very simple for people to begin to use the container. Sure, you only need 1/10 of the capabilities of a full IoC container, but the IoC container already has the API feel that the programmer already likes. Also, putting just a thin layer over the original container also ensures that the automocking container behaves as expected. If i start creating an API for an automocking container, it will inevitably start to look like Castle; if Kaleb makes the API it will look like Autofac, etc. It would be ultimately awkward if I, as a Castle user, had to use an IoC API for unit testing that looks like StructureMap or Autofac. Kaleb mentioned to me earlier that the old Automocking container seemed to inherit many traits from Autofac. If a Ninject user tried using it, he would be "turned off" by the way it felt very unlike Ninject. 

I think we all agree what an IoC container does. I think we all understand that mocking really doesn't use extended features of a regular IoC container. But I think we can all also acknowledge that there are exceptions to this rule. And in the case of those exceptions, I think it would be nice if we simply put a thin layer over the regular IoC container, so those features are still accessible if necessary. Honestly, it's so easy to do, why not?

Tim Kellogg

Daniel Cazzulino

unread,
Apr 9, 2011, 1:18:27 AM4/9/11
to moq...@googlegroups.com

I think it does, as long as the abstraction doesnt leak

/kzu from Android

Derek Greer

unread,
Apr 9, 2011, 11:44:06 AM4/9/11
to moq...@googlegroups.com
I agree that a thin layer that hooks Moq with an existing framework would fulfill the needs of an auto-mocking container.  My points were really just to answer your questions concerning how I saw the two needs as different, not to suggest it would be wrong to use an existing container.  

That said, ideally an auto-mocking container would only ship with the bits it really needs to function.  I wouldn't think writing the code to handle determine the dependencies to mock would be a significant amount of work.  It would also be a lot faster.  I'm not sure how all the containers are designed, but the Unity container uses a Chain-of-Responsibility implementation to pass an object through a pipeline of strategies, each of which checks to see if a given policy applies.  That's a lot of overhead when you only want to do one thing: mock the type.  My recommendation would be to keep it lean and mean.

If you do decide to use an existing container, I don't see a significant value to exposing the underlying container's API.  There's really only one thing in common between the two from an API need perspective and that is the ability to choose which ctor is used when you create the SUT.  I agree with Daniel, keep the container tucked behind the abstraction.  In doing so, you won't need any sort of adaptors for different containers, complex setup, scanning, etc.  People shouldn't care how its implemented and particularly that it even relies upon an IoC container.


Derek

Tim Kellogg

unread,
Apr 10, 2011, 2:10:18 AM4/10/11
to moq...@googlegroups.com
Yes, in unit testing the idea is to isolate a single unit by mocking all other units that it accesses. However, a full test suite also includes integration and functional tests. In integration tests, you identify a collection of units, sometimes referred to as a module, and isolate the module. One common scenario for integration testing is to write tests in C# that do CRUD operations against tables, views and stored procedures. In this case you are testing not only database logic but also ORM mappings and data access/manipulation methods (C#). Often, the top C# layer accesses other modules unrelated to the database and ORM mappings. Since this isn't functional testing (where nothing is mocked) we want to mock everything that isn't related to the database layer module. 

This is the primary reason why you still want a fully functional IoC container with just a thin layer on top for mocking. A side effect of integration tests is that I can also test that my [complicated] registrations and object graphs work as expected while still auto-mocking anything outside the module. If we abstract the auto-mocking container into a separate container we completely lose these abilities.

On a side note, Daniel, when you use the phrase "as long as the abstraction doesn't leak" do you mean, "as long as we make a clear distinction between what is for mocking and what isn't"? My plan is to take an existing container API and append a .Mock<>() method (and overloads). i.e.:

interface Container {
  void Register(...);
  T Resolve<T>();
  Mock<T> Mock<T>();
}

Does this cause the abstraction to leak?
Tim Kellogg

Derek Greer

unread,
Apr 10, 2011, 8:46:17 AM4/10/11
to moq...@googlegroups.com
Yes, writing course-grained tests sometimes requires mocking a subset of the actual dependencies, but is this really something an automocking container should be concerned with?  When I have this need, I usually tie into the initialization process and override the selected registrations I want (e.g. replacing the real database with an in-memory database).

There's some value to be added by making registration overrides easier to write and less obscure, but it seems this could be facilitated fairly easily by an extension method:

   _container.Mock<ISomeService>();

    public static class SomeContainerExtension
    {
        public static Mock<T> Mock<T>(this IContainer container)
        {
            var mock = new Mock<T>();
            _container.For<T>.Use(ctx => mock.Object);
            return mock;
        }
    }


Derek

Naeem Khedarun

unread,
Apr 10, 2011, 11:46:26 AM4/10/11
to moq...@googlegroups.com
This is a great discussion, well done guys. I agree that an auto mocking containers responsibilities are a subset of an IoC container. And perhaps the emphasis within this project could be to make setting up mocks as simple as possible.

So how about building the API around the things that are really important when auto mocking, such as initialisation, construction, and a little around lifestyles. For everything else exposing the underlying container is a great idea, we can't predict all the ways people want to use the library, so let's give them the option of doing anything they want.

Tim Kellogg

unread,
Apr 10, 2011, 3:23:09 PM4/10/11
to moq...@googlegroups.com
Derek,

I think I understand your point. If you're working on an open source project that uses an IoC container via the Common Service Locator (CSL) you wouldn't already have a full featured IoC container included in your project. Therefore, it seems a little silly to include the full Castle.Windsor (or whatever you would use) just so you can have mocks created automatically. To that very valid point, we will prioritize the creation of an Auto-Mocking container that implements the CSL but does nothing but mock services. However, as Naeem points out, it would be short-sighted dismiss the value that a full featured IoC container can bring to various forms of testing.

Daniel,
I think I understand now what you mean by keeping the abstraction from leaking. I think its safe to assume that over the course of the coming months and years the auto-mocking API will expand. We might as well isolate this growth into a separate interface, available from a "Mock" property off of the container so as not to cloud the scope of the regular IoC API.

Naeem,
Thank you for your input. Can you please elaborate on the features you would like to see in an auto-mocking container? I know what I want, but I would like to hear (independently) the details of what you're looking for.

Tim Kellogg
Reply all
Reply to author
Forward
0 new messages