使用Moq模拟具有Unity IoC依赖项的类

Question

So, we have a custom mock class already that we created manually. -- it works great for our existing tests, but we also want to be able to verify that given methods were called on it (ie mock.Verify ). -- I could just add a million booleans, one for each method and property in our mock class to verify that each method was called with the correct parameters, but this would get really ugly and hairy, and ultimately wouldn't have the same fidelity as using Moq.

If the mock class didn't have injected dependencies, I could just create a new one using new Mock<MyMockObject>() , and everything would work fine. -- But it also has dependencies injected automatically by Unity, so in this case, it would fail, and leave those properties as null.

Is there any way to make the two play nicely together? -- Any way to tell Moq to use Unity to create the class? -- Or any way to tell Unity to populate the class created by Moq? -- Should I be using a different mocking library that knows about Unity?

Here's a Console Application example of what I'd like to get working; right now the Bar property comes in as null (because Moq doesn't know about my unity container):

public class Bar: IBar
{
    public string Text { get; set; }
}

public class Foobar: IFoobar
{
    public virtual string Foo { get; set; }

    [Dependency]
    public virtual IBar Bar { get; protected set; }
}

public class Program
{
    public static void Main(string[] args)
    {
        using (var uc = new UnityContainer())
        {
            // Injected by specific unit test:
            uc.RegisterInstance<IBar>(new Bar() { Text = "Hello World!" });

            // This way works, but I can't verify if methods get called.
            Console.WriteLine
            (
                uc.Resolve<Foobar>().Bar.Text
            );

            // This way I can verify if certain methods were called, but "Bar" will never be
            // populated, so the following will throw a NullReferenceException.
            Console.WriteLine
            (
                new Mock<Foobar>().Object.Bar.Text
            );
        }
    }
}

---

EDIT:

Guys, please don't get hung up on the interop between Unity and Moq, or on unit testing philosophy. -- Obviously this code and scenario is very simplified. -- I'm asking in general on how to make something work.

If it helps you to remove Unity from the situation and think of this question as a Moq only question, that's fine, at that point, the question would be:

If I have a pre-constructed Mock Object (it comes from a factory, or magic fairies, or my uncle gave it to me, it doesn't matter, I have an existing mock object): how do I create a Mock wrapper around that existing object instance to intercept the calls that are made to it? (Mainly, I want to intercept in order to verify that certain methods were called with certain parameters, or certain properties were called, etc., via the Verify keyword.)

So, instead of new Mock<IFoo>() , I want to do something like Mock.GetWrapper(existingFooInstance) . -- Is this possible? -- It looks like there used to be libraries that did this, but what I've found seems to be unmaintained, and not super useful.

Answer 1

so what exactly do you want to test there? Your Foobar class? Then you should mock everything but this class. If you want to do verifications on the Bar property, you could mock it like this:

var barMock = new Mock<IBar>();
barMock.SetupGet(x => x.Text).Returns("Hello World");
uc.RegisterInstance<IBar>(barMock.Object);

After that, you can check if anything on the barMock was called:

barMock.VerifyGet(x => x.Text);

On another note, if you do unit test you should isolate your class under test as much as possible, so using Unity to actually create it doesn't really seem like the best idea. In our environment we usually inject everything into the constructor, which would allow us to create the Foobar Object in the Unit Test without any "Unity Magic". Maybe you could think about that instead of using the [Dependency] Attribute.

Answer 2

First of all, if this is unit testing (unclear from your question), using a DI container such as Unity is overkill - you are only supposed to have 1 real class for any given scenario, and the rest should typically be mocks or stubs that are created with the new keyword.

Secondly, constructor injection should always be the first choice for injecting dependencies. For one, you can ensure they are never null for a given scenario, which simplifies the code that uses the field/property.

public class Foobar: IFoobar
{
    public FooBar(IBar bar)
    {
        // using a guard clause ensures your dependency can
        // never be null.
        if (bar == null)
            throw new ArgumentNullException("bar");
        this.Bar = bar;
    }

    public virtual string Foo { get; set; }

    public virtual IBar Bar { get; private set; }
}

Also, IMO using a container's built-in attributes (such as [Dependency] ) to inject properties is a bad choice because it means that your application is dependent on a specific DI container. Furthermore, property injection should only be used for optional dependencies (that is, dependencies that are ignored by your application if they are null). So, use constructor injection for required dependencies. If they are optional, either find a convention-based way to inject the dependency, or use a custom attribute (from your application) to signal injection which you can also use for tests. Then you don't need to involve a DI container in testing.

I recommend you read the book Dependency Injection in .NET . Clearly, you are doing something wrong if you think your unit tests need a DI container and you believe that using constructor injection is somehow "more difficult" than property injection. I can't tell you exactly what is wrong though because your example is oversimplified and doesn't demonstrate why you think you need a container for unit tests.

Dependency Injection is about making an application loosely-coupled, which usually involves significantly limiting (and refactoring) the application design to make it follow the DI pattern. The use of a container is completely optional. This makes it extremely simple to compose your application with a DI container, and compose unit tests manually. In fact, putting a DI container in your unit tests only serves to make your tests more difficult to understand.