测试 Unity 运行时配置
DI 容器和特定的 Unity 困扰我的一件事是，因为那是我使用的容器。如果我忘记注册一个类型，当我稍后尝试解析需要忘记注册的类型时，程序就会崩溃。过去，我显式调用 new，编译器会为我检查这一点，但现在没有强制检查。
我的大部分解析调用都是在程序初始化期间发生的，所以问题不是那么大。 但我仍然想测试它，一个想法可能是设置容器注册，然后扫描程序集以调用container.resolve。
我从来没有见过这样的事情，所以我走错了路吗？应该进行单元/集成测试吗？
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 resolve 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?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
某些容器 (StructureMap IIRC) 具有您可以调用的方法来要求它们进行自我诊断，但 AFAIR Unity 没有此类方法。
我一直对自我诊断方法是否具有多大价值持怀疑态度。它仅告诉您已经注册的组件内部一致，但您仍然可以要求容器解决最初从未配置的内容。假设您配置了 Foo、Bar 和 Baz。这些可能是一致的，但如果你要求 Qux 呢？
自我诊断永远不会发现这种情况。
我宁愿推荐一套集成测试，尝试解决所有适当的输入。如果您遵循Register Resolve Release 模式，则输入集应该针对给定的应用程序明确定义解决方法。
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.