Should you unittest the code that registers components into your IoC container?
If so, how?
In spring you can have a unit test that simply loads the application-context without asserting anything. It's actually a fairly useful test in conjunction with automatic build, since spring complains about a lot of problems when loading the full context.
It somehow feels wrong to me to have the IoC container running in my test-projects. I also noticed that most of the bugs that are caused by dependencies not being resolved are caused by the order dependecies are resolved, this is very hard to test right and is not something I'd want to do as a unit test.
Usually I use Debug.Assert statements in the initialization routines of my classes. This gives me an early warning system for IoC related errors and also helps specify dependencies better in my code.
What I do with the Guice IoC container, is that first I produce the classes for some feature using TDD without Guice (these are unit tests). Then I create an integration test for that feature with Guice. At that point the IoC configuration (Guice module) is incomplete, so the integration test will fail. Using TDD, I add the IoC configuration step by step until the integration test passes. I won't add any @Inject annotation, line of configuration or scope declaration, unless it is required to pass a test. As a result, I will have integration (or acceptance) tests making sure that the IoC configuration is right and complete.
This same method should work with any IoC container or other system, whose configuration is so complex that it may break - don't write any configuration unless it is require to pass a test.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With