Unit test for a method that takes an instance through Resolve<T> of Autofac

Question

I'm facing a problem trying to implement a unit test for a method on a service. The architecture of the project is a little bit cumbersome, to say the less...

The problem is that within the method to test it calls another method to take an instance of another service, here is the little monster:

public void SendOrderEmail(string orderCode)
{
    Order order= GetOrderService().SerachByCode(orderCode);
    .... Send email with the order ....
}

private IOrderService GetOrderService()
{
    return OrderService = AutofacDependencyResolver.Current.ApplicationContainer.Resolve<IOrderService>();
}

Please, don't ask why a service calls another service or why is that service not injected at the constructor, as i said the architecture of this project is weird in some points. I just need to know what is the way to implement a unit test for a method like that.

Thank you!

Answer 1

Late to the party, but I also have to work with legacy code, that instantiates objects like new MyClass(). I can't change the consumer type construction mechanism, so constructor injection is a no-go. The best I can do atm is to replace instantiation using a locator, like this:

var myVar = ContainerLocator.Container.Resolve<IMyType>();

I need to unit tests that code, so I set up the unit test like this:

[TestClass()]
public class MyClassTests
{
    private Mock<IDateTime> _mockClock = new Mock<IDateTime>();
    private Mock<IMyApp> _mockMyApp = new Mock<IMyApp>();

    [TestInitialize]
    public void TestInitialize()
    {
        // This is how it would be done for the well-behaved ones, 
        // but I can't us it in some cases
        _mockClock.Setup(x => x.Now).Returns(new DateTime(2001, 01, 01));

        // IMyApp is used via the locator somewhere deep in the code,
        // so the DI container needs to be built, locator set up:

        var builder = new Autofac.ContainerBuilder();
        builder.RegisterInstance(_mockMyApp.Object).As<IMyApp>();
        ContainerLocator.Container = builder.Build();

        _sut = new myClass(_mockClock.Object);
    }
}

Answer 2

I would refactor a little the code, let the class that implement this method have IOrderService injected through the constructor, save the instance and then use it, this way you can inject your fake IOrderService during the test (or use Automock) :)

If you really really can't change the constructor, you can use a property to set IOrderService

---------------- edit Since i got some downvote on this answer I've tried to get to understand better what is going on. I'm not sure about this, but seems like you can't edit this class you wrote about, you just want to test it. Well if that is the case i think i can still give you some advices. Advice number one: make a test project, link the class file, make a new file with a class like the following one.

class AutofacDependencyResolver {

    public static Current { get; private set; }

    public ILifetimeScope ApplicationContainer { get; private set; }

    public AutofacDependencyResolver(ILifetimeScope scope) {
        Current = this;
        ApplicationContainer = scope;
    }
}

Since the class you need to test is linked it's gonne to compile it and you just can now achieve what you need.

The other (and i think better) advice is do not test stuff you did not wrote / can't modify. What i'm suggesting is writing an adapter, so a class that use the one you can't modify as a black box. In this case i think you need to test the email, so just check the email output the address stuff like that and ignore the rest.

the people who wrote those classes should have followed solid principles...

Answer 3

As others have said, and you're probably aware yourself anyway, you really want to refactor classes like this and use constructor injection if at all possible. Service location is generally considered an anti-pattern (https://blog.ploeh.dk/2010/02/03/ServiceLocatorisanAnti-Pattern/) and it specifically makes unit testing like this harder and less transparent.

However, if you absolutely can't refactor, you can still make methods like this somewhat testable by just providing different registrations for the services you're accessing via service location.

In your case, if you have:

public class EmailSender
{
    public void SendOrderEmail(string orderCode)
    {
        Order order = GetOrderService().SearchByCode(orderCode);
        //....Send email with the order ....
    }

    private IOrderService GetOrderService()
    {
        return AutofacDependencyResolver.Current.ApplicationContainer.Resolve<IOrderService>();
    }
}

...and you're looking to specifically run unit tests over SendOrderEmail to validate the logic surrounding your IOrderService implementation (which could be easily covered by a separate test), the other classes implied there might look like:

public class AutofacDependencyResolver  // this is problematic but we can't change it
{
    public AutofacDependencyResolver(IContainer applicationContainer)
    {
        ApplicationContainer = applicationContainer;
    }

    public IContainer ApplicationContainer { get; }
    public static AutofacDependencyResolver Current { get; private set; } 

    public static void SetContainer(IContainer container)
    {
        Current = new AutofacDependencyResolver(container);
    }
}

public static class ContainerProvider   // this sets up production config across your app
{
    public static IContainer GetProductionContainer()
    {
        var builder = new ContainerBuilder();
        builder.RegisterType<RealOrderService>()
            .As<IOrderService>();

        // register all other real dependencies here

        return builder.Build();
    }
}

With that setup, you only need to provide mocks which are required for the specific method you're testing, assuming you can set your container within AutofacDependencyResolver easily in order to have production and test configuration running in parallel. That might look like the following, using xUnit, Moq and Autofac in a test project:

public class EmailSenderTests
{
    private readonly Mock<IOrderService> _orderService;
    public EmailSenderTests()
    {
        // to set up the test fixture we'll create a mock OrderService and store a reference to the mock itself for validation later on
        _orderService = new Mock<IOrderService>();
        var mockOrder = new Order();
        _orderService.Setup(os => os.SearchByCode(It.IsAny<string>()))
            .Returns(mockOrder);
    }

    private IContainer GetTestContainer()
    {
        // here we're adding just one registration we need, setting the mocked OrderService instance to be used for IOrderService
        var builder = new ContainerBuilder();
        builder.Register(c => _orderService.Object)
            .As<IOrderService>();
        return builder.Build();
    }

    [Fact]
    public void SendEmail()
    {
        AutofacDependencyResolver.SetContainer(GetTestContainer()); // set the test container on the global singleton
        var sender = new EmailSender();
        sender.SendOrderEmail("abc");   // internally the email sender will retrieve the mock IOrderService via service location

        // make any assertions here, e.g.

        _orderService.Verify(os=>os.SearchByCode("abc"), Times.Exactly(1));
    }
}