依赖注入帮助你单元测试你的代码非常好。但是我们如何测试在运行时最终是否注入了正确的依赖关系？例如，我有一个服务类，它包含一个服务验证器列表。由于验证器列表是由DI容器注入的，我们如何确保正确的验证器被注入？如果某些开发人员错误地从列表中删除了验证程序，该怎么办？即使我们在依赖注入中编写测试，我们也无法在不破坏封装的情况下断言所有依赖。唯一的方法是在服务的验证行为上进行断言的集成测试。如果服务行为复杂，那么编写集成测试就变得很困难。有任何想法吗 ？？你如何测试依赖注入？
套用你的问题：
我已经测试我的应用程序，它们都工作的各个组成部分，但我怎么知道应用程序作为一个整体的作品？
好消息
考虑多么好的一个位置，你是，相比于在一个位置被问：
现在我已经写了这些代码，我怎么知道应用程序的工作？
您发现并删除了单元测试中的错误。使用依赖注入样式进行编码使依赖性清晰并消除对全局变量的依赖。这些技术本身就意味着你会有更少的错误，并且特别是当整个应用程序放在一起时只显示自己的更少的错误。
测试更大
现在，移动在回答你的问题，你可以写一个自动测试断言特定的验证是由您的依赖注入容器返回。更重要的是，我喜欢书面方式测试，： -
你可能要替换访问数据库，当前服务器时间，网络服务等与测试双某些对象。这很容易，因为您正在使用依赖注入。
除非一个类特别麻烦，否则我倾向于在这个级别测试，因为它允许更多的测试在重构过程中存活。循环复杂度为1的类如果作为较大测试的一部分进行操作，则不需要单独测试。循环复杂度较高的类可能。
很多测试，但它的工作？
即使这样，你可能会想，但是整件事情是否奏效？
为了最终回答这个问题，您需要测试应用程序的最终形式。对于Web应用程序，这意味着将其部署在具有适当数据库和真正防火墙的适当服务器上，然后您可以手动测试或测试诸如Selenium之类的东西。
注入正确依赖关系的失败会导致注入组件意图做的任何功能的灾难性错误。没有必要测试每个组合，但轻轻触摸每个组件。
我认为集成测试是正确的答案，但你是对的，有些东西可能很难测试。 – Kevin
一些依赖注入框架（如果不是大多数）允许您让容器验证所有注册并测试是否可以创建每个注册。如果可以，请在应用程序启动时触发此验证。这可以防止在不能创建所有依赖关系时启动应用程序，这样您可以在运行（或调试）应用程序时立即找到DI配置错误。 – Steven
@Steven hibernate是否有这样的验证工具？ – mauryat