如何测试依赖注入？
依赖注入可以帮助您很好地对代码进行单元测试。但是我们如何测试在运行时最终是否注入了正确的依赖项？例如，我有一个服务类，它接受服务验证器列表。由于验证器列表是由 DI 容器注入的，我们如何确保注入正确的验证器？如果某些开发人员错误地从列表中删除验证器怎么办？即使我们确实对依赖项注入编写了测试，我们也无法在不破坏封装的情况下对所有依赖项进行断言。唯一的方法是集成测试，断言服务的验证行为。如果服务行为很复杂，那么编写集成测试就会变得困难。有什么想法吗？
Dependency injection helps you unit test your code pretty well. But how do we test if the right dependencies are injected finally at run time ?? For example I have a service class which takes in a list of service validators. Since the list of validators is injected by a DI container, how do we make sure that the right validators are injected ?? What if some developer mistakenly removes a validator from the list. Even if we do write tests on the depen dency injection, we can't assert on all dependencies without breaking encapsulation. The only way is an integration test which asserts on the validation behaviour of the service. If the service behaviour is complicated, then it becomes difficult to write integration tests. Any ideas ??
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
解释一下您的问题：
我已经测试了应用程序的各个组件，它们都可以正常工作，但是我如何知道整个应用程序可以正常工作？
好消息
考虑一下有多好与询问以下问题相比，您所处的位置：
我现在已经编写了所有这些代码，我如何知道应用程序是否有效？
您在单元测试中发现并删除了错误。以依赖注入风格进行编码使依赖关系变得清晰并消除了对全局变量的依赖。这些技术本身意味着您会遇到更少的错误，尤其是只有当整个应用程序放在一起时才会出现的错误。
测试更大
现在，为了继续回答您的问题，您可以编写一个自动化测试来断言依赖项注入容器返回特定的验证器。更好的是，我喜欢编写以下测试： -
您可能想要用测试替身替换访问数据库、当前服务器时间、Web 服务等的某些对象。这很容易，因为您正在使用依赖注入。
除非某个类特别麻烦，否则我更喜欢在这个级别进行测试，因为它允许更多测试在重构中幸存下来。如果作为较大测试的一部分进行测试，则圈复杂度为 1 的类不需要独立测试。具有较高圈复杂度的类可能会。
大量测试，但它有效吗？
即使如此，您可能会想，但是整个事情有效吗？
要最终回答这个问题，您需要测试应用程序最终形式。对于 Web 应用程序，这意味着将其部署在具有适当数据库和真正防火墙等的适当服务器上。然后您可以手动测试或使用 Selenium 之类的东西进行测试。
未能注入正确的依赖项将导致注入组件的任何功能出现灾难性错误。不必测试每个组合，只需轻轻接触每个组件即可。
To paraphrase your question:
I have tested the individual components of my application and they all work, but how do I know the application as a whole works?
Good News
Consider how good a position you are in, compared to being in a position to ask:
I've written all this code now, how do I know if the application works?
You found and removed bugs in unit test. Coding in a dependency injection style made dependencies clear and removed reliance on global variables. These techniques in themselves mean you would have less bugs, and particularily less bugs that only show themselves when the entire application is put together.
Test Bigger
Now, to move on to answer your question, you could write an automated test to assert that a particular validator is returned by your dependency injection container. Better yet, I favour writting tests that:-
You might want to replace certain objects that access the database, the current server time, a web service, etc with a test double. This is easy because you are using dependency injection.
Unless a class is particularly troublesome, I prefer to test at this level because it allows more tests to survive refactoring. Classes with a cyclomatic complexity of 1 do not require stand-alone testing if exercised as part of a larger test. Classes with higher cyclomatic complexity may.
Lots of tests, but does it work?
Even then, you may be wondering, But does the whole thing work?
To finally answer this question, you need to test the application in its final form. For a web application, this means deploying it on a proper server with a proper database and the real firewall, etc. Then you can manually test or test with something like Selenium.
Failures to inject the correct dependencies would result in a catastrophic error in whatever feature the injected component is meant to do. It is not necessary to test every combination but lightly touch upon each component.