Test Unity runtime configuration
One thing that bothers me with DI containers and particular Unity, since that's the one I use. Is that if I forget to register a type, the program will crash, when I later try to resol开发者_StackOverflow中文版ve a type which needed that forgotten registration. I the old days with explicit calls to new, the compiler would check this for me, but now there is no forced checks.
Most of my resolve calls take place during the program initialization, so the problem is not that big. But I would still like to test it, an idea could be to setup the container registrations and then scan the assemblies for calls to container.resolve.
I have never seen something like it, so am I going down a wrong path? and should instead unit / integration test it?
Some containers (StructureMap IIRC) have methods that you can invoke to ask them to self-diagnose themselves, but AFAIR Unity has no such method.
I've always been somewhat doubtful that a self-diagnostics method provides much value. It only tells you that the components you have already registered are internally consistent, but you could still ask the container to resolve something that was never configured in the first place. Let's say that you have Foo, Bar and Baz configured. Those may be consistent, but what if you ask for Qux?
Self-diagnostics would never catch such a scenario.
I would rather recommend a suite of integration tests that attempts to resolve all appropriate inputs. If you follow the Register Resolve Release pattern, the set of input to the Resolve method should be well-defined for a given application.
精彩评论