Question

I have a PRISM application that consists of several modules (IModule) in which the bootstrapper passes each module the DI container so that each module is able to inject/resolve services. This means that each module has its own “Composition Root” in which types are injected/resolved and I was wondering what best practices say about unit testing them.

For example, let’s say I have a Resources modules which is responsible for creating and registering services that fetch data from various data sources. Let’s say I implement the IModule.Initialize method as follows :

void Initialize()
{
ISomeDataService someDataService = _container.Resolve<SomeDataService>();
someDataService.Connect();
_container.RegisterInstance<ISomeDataService>(someDataService);
}

The Resources module creates an instance of SomeDataService, opens a connection, and registers it so that the other modules can use it. Note : This isn’t actually how I do it, this is just for a quick illustration.

Now from a unit-testing standpoint how do I test the Initialize method? I want to test two things here :

1. ISomeDataService.Connect() method is being called.
2. IUnityContainer.RegisterInstance is being called and supplied the correct service.

Since Initialize() is in charge of actually creating concrete types and registering them, it would seem I’m out of luck when it comes to supplying it with my own ISomeDataService mock. Now it does try to Resolve the concrete type SomeDataService (which is basically the same thing as doing new SomeDataService()), so I could try to mock the concrete type SomeDataService and override the methods I want to test but this becomes a problem when the concrete type has side-effects such as the ChannelFactory which immediately upon instantiation tries to resolve for a valid WCF binding and throws an exception when it fails. I can avoid that failure by supplying it with a valid binding but I don’t think a unit-test should depend on such things.

Any advice? One idea I had is as follows :

void Initialize()
{
if (_container.IsRegistered<ISomeDataService>())
   {
   someDataService = _container.Resolve<ISomeDataService>();
   }
else
   {
   someDataService = _container.Resolve<SomeDataService>(); // or new SomeDataService()
   }

_container.RegisterInstance<ISomeDataService>(someDataService);
someDataService.Connect();
}

Done this way I can mock ISomeDataService instead of the concrete type SomeDataService and all is well, but I don’t know if this is the right approach… I’m sure I’m doing this wrong and there must be some other way.

Answer 1

This is an interesting question.

Looking at the example provided, there’s actually three things being tested:

• Initialize registers your service
• ISomeDataService calls Connect
• SomeDataService is properly instantiated.

Typically, I would defer Connect until some other later point as this is similar to doing work in the constructor, and it suggests that the module is doing more than one thing. If you were to remove the Connect method this would be trivial to test. But, your needs may vary, so I digress…

Each of these three things should be separate tests. The trick is finding the appropriate “seam” to decouple the instantiation from the registration and substitute the service with a mock so we can verify the Connect method.

Here’s a small change to the above:

public void Initialize()
{
    ISomeDataService service = DataService;
    service.Connect();
    _container.RegisterInstance<ISomeDataService>(service);
}

internal ISomeDataService DataService
{
  get { return _service ?? _service = _container.Resolve<SomeDataService>(); }
  set { _service = value;}
}

Alternatively, you can use the Subclass to Test pattern:

protected internal virtual ISomeDataService GetDataService()
{
  return _container.Resolve<SomeDataService>();
}

A few interesting points from the above:

1. you can test registration by assigning a mock service to the subject under test, call Initialize and then attempt to resolve the service from the container manually. Assert that the resolved service is the same instance as your mock.

2. you can test Connect by assigning a mock, call Initialize and then verify that Connect was called.

3. you can test that the service can be instantiated by filling the container with the appropriate dependencies and retrieve the instance from the DataService property or the base GetDataService() (if you’re using Subclass To Test).

It’s the last one that is the contention point for you. You don’t want to add wcf configuration for your tests. I agree, but because we have decoupled the behavior of the module in the first two tests the configuration is only needed for the last one. This last test is an integration test that proves you have the appropriate configuration file; I would mark this test with an Integration category attribute and run it with other tests that load and initialize all modules with their appropriate config. After all, the point is to verify that it all works — the trick is to get meaningful feedback for isolated components.

One last point, the code shown in your question suggests you would test the subject by filling it with mocks. This is very similar to what I’m proposing here but the main difference is the semantic meaning: the mock is a part of the responsibilities for the subject, it is not a dependency that is injected through the container. By writing it this way it is clear what is part of the module and what is a required dependency.

Hope this helps…