IoC containers: Autoregistration tests groundwork

Tags: IoC, Autoregistration, groundwork, code, demo, test

I have put together an assembly containing some types used to test the autoregistration features of different Inversion of Control containers.

I will put some IoC containers (starting with Windsor) through a set of tests over these classes. The IoC container will have to find a concrete class, find an implementation for an interface, and find all implementations of a interface where multiple types implement it.

The model classes that I chose for testing autregistration are a bit generic. A business process needs two services which are interface types. The constructor is BusinessProcess(ICustomerService customerService, IOrderService orderService) The business process is a concrete class, and there is one implementation of each of the service interfaces. Autoregistration should find these. It should register the BusinessProcess type as itself, but register CustomerService for ICustomerService and OrderService for IOrderService.

There is also an interface, IValidator, which has three different implementations. This models the case where a set of validation rules are all checked and errors are reported if any of them fail. The autoregisration must be also capable of returning a list containing all three of the validators.

In my opinion, an autoregistration system must be able to do this in order to be fexible enough to use in production.

The test classes code is here but the important interfaces are:

    public interface ICustomerService
    {
        string Customers();
    }

    public interface IOrderService
    {
        string Orders();
    }

    public class BusinessProcess
    {
        private readonly ICustomerService customerService;
        private readonly IOrderService orderService;

        public BusinessProcess(ICustomerService customerService, IOrderService orderService)
        {
            this.customerService = customerService;
            this.orderService = orderService;
        }
    }

    public interface IValidator
    {
        bool IsValid(object value);
    }

Of course, they don't actually do anything, we're just testing how they fit together.

The tests are:

1) Can the autoregistration make an instance of BusinessProcess? This demonstrates the basics - that the autoregistration has found service types and registered them as thier interfaces, and either found the BusinessProcess concrete type and and registered it as itself, or can work without having that type registered.

2) Can the autoregistration return the same instance of BusinessProcess twice? The container must either make singletons by default, or be configured to make a singleton.

3) Can the autoregistration return two different instances of BusinessProcess? The container must either make transient instances by default, or be configured to make a transient instance.

4) Can the container return a transient BusinessProcess instance, but with singleton services inside it? This demonstrates that different components can be configured to have different lifespans. There must be some way to target individual types that have been autoregistered.

5) Can all three types that implement IValidator be instantiated? This demonstrates that the container can handle collections of types.

6) Can one of the IValidator types be excluded? This demonstrates that custom filtering can be done.

Add a Comment