Unittesting IoC registration?

Question

Should I exclude code that registers components in your IoC container?

If so, how?

Answer 1

In spring, you might have a unit test that just loads the application context without claiming anything. This is indeed a pretty useful test in conjunction with auto-build, as spring complains about a lot of problems loading the full context.

Answer 2

For some reason, it seems awkward for me that the IoC container works in my test projects. I also noticed that most errors caused by unresolved dependencies are caused by order dependencies, resolved, it is very difficult to check correctly, and this is not what I would like to do as a unit test.

I usually use Debug.Assert statements in the initialization procedures of my classes. This gives me an early warning system for IoC related errors and also helps to better identify dependencies in my code.

Answer 3

@aku, @krosenvold, and @mookid make a convincing argument for verifying dependency configuration.
I do not think this is unit testing. What are you experiencing? You are not trying to use unit test the container itself (presumably this is not code that you wrote or maintain).
What you are trying to verify is that all dependencies of a particular type can be created and that the type can be resolved. This sounds like a pretty useful system test or integration test that will take place in your ongoing integration environment.
Therefore, when you have the binaries that pass the unit test, you can create a container and run the configuration for the container on a machine that reflects your production environment, and verify that each of the types that the container can resolve can be virtually all their dependencies can be created.
It would be nice to run this in a new virtual machine to which you applied your last installer.

Answer 4

What I do with the IoC Guice container is that I first create classes for some function using TDD without Guice (these are unit tests). Then I create an integration test for this function with Guice. At this point, the IoC configuration (Guice module) is incomplete, so the integration test does not complete. Using TDD, I add the IoC configuration step by step until the integration test passes. I will not add any @Inject annotations, configuration lines or region declarations unless this is required to pass the test. As a result, I will have integration (or acceptance) tests to make sure that the IoC configuration is correct and complete.

The same method should work with any IoC container or other system whose configuration is so complex that it can break - do not write any configuration if you do not need to pass the test.

Answer 5

Since your components may have their own dependencies or do some initialization, I would consider this scenario using UT.

Something like

iocContainer.Register(typeof(MyService1)); service = iocContainer.Get(typeof(MyService)); Debug.AssertNotNull(service); 

Answer 6

I use Windsor in an ASP.NET MVC project where I wrote a simple test to make sure that all controllers can be created (i.e. their dependencies can be resolved).

I have a test for each website configuration (for example, "development", "test", "someProductionSite", etc.), where I create my Windsor container with this specific configuration and go through all the non-abstract IController implementations. checking that I can resolve an instance of each of them.

Since the factory controller is the only entry point to the application that will lead to the container. Resolve (...), I am 100% sure that all configurations are valid.

As a rule, I have found that written tests that function as statements about the entire system are extremely useful and valuable.

eg. I also claim that all controller actions are virtual, which is a requirement because I use Castle's automatic transaction management to manage the controller’s transactions with transactions.

Answer 7

This can be useful because some dependency injection structures (like Unity) have weird rules for choosing which constructor should call. I would definitely recommend unit testing to make sure that registering and creating your type is successful.

Answer 8

Answer this question specifically for Castle Windsor :

Castle Windsor: how to check if all registered components are allowed?