在我的分析器报告中,我越来越多地看到依赖注入的基于模拟的测试结果。许多依赖项都是静态的,但是因为我们想要单独测试方法,所以它们会更改为实例成员,如下例所示:
class ShortLivedThing {
IDependency1 dep1;
IDependency1 dep2;
IDependency1 dep3;
...
int TheRealData;
// Constructor used in production
public ShortLivedThing() {
dep1 = new Dep1(); dep2 = new Dep2(); dep3 = new Dep3();
}
// DI for testing
public ShortLivedThing(IDependency1 d1, IDependency2 d2, IDependency3 d3) {
dep1 = d1(); dep2 = d2(); dep3 = d3();
}
}
反过来,依赖关系大部分时间都有其他依赖关系,依此类推。这导致每次在测试之外完成方法调用时实例化(主要是“静态”)对象的树。每个对象都非常小(只有几个指针),但树效果会使其变得不断增加性能。
我们能做些什么呢?
答案 0 :(得分:8)
在我看来,您需要利用适当的依赖注入框架可以为您提供的功能。不要使用不同的构造逻辑进行测试/生产。
对于弹簧,单次注射仅在容器启动时执行。每次都进行原型注射。如果正在进行单元测试,每次完成接线时都会完成接线。所以剖析单元测试通常不是一个好主意。
也许你使用的单例范围太少,原型范围太多? (原型=每次新实例)
关于spring注入的好处是你可以使用范围代理,这意味着你的对象图可以是这样的:
A Singleton
|
B Singleton
|
C Prototype (per-invocation)
|
D Singleton
|
E Session scope (web app)
|
F Singleton
每个请求每个会话只会创建一个C实例和一个E实例。 A,B,D和F是单例。如果它不是一个webapp你默认没有会话范围,但你也可以制作自定义范围(一个窗口桌面应用程序的“Window”范围听起来很酷)。这里的线索是,您可以在任何级别“引入”范围,实际上您可以拥有十层单例对象,并突然显示会话作用域。 (这可以彻底改变您在分层架构中实现某些交叉功能的方式,但这是一个不同的故事)
我认为这确实可以在DI模型中创建最小的对象。
虽然这是Spring for Java,但我相信其他一些DI框架应该支持类似的功能。也许不是最简约的。
答案 1 :(得分:2)
我认为你应该只有“DI构造函数”。您可以将此构造函数称为测试和生产。
class ShortLivedThing {
IDependency1 dep1;
IDependency1 dep2;
IDependency1 dep3;
...
int TheRealData;
public ShortLivedThing(IDependency1 d1, IDependency2 d2, IDependency3 d3) {
dep1 = d1; dep2 = d2; dep3 = d3;
}
}
这样,每次在测试之外进行方法调用时,都不会出现实例化对象树的问题。当然,对于生产,您必须正确地在之外参与对象本身,这是一件好事。
总结:不要去50%DI / 50%硬编码,去100%DI。
答案 2 :(得分:1)
如何传递参考资料?
答案 3 :(得分:1)
如果您关注的是测试速度慢,请尝试并行运行它们,不要让测试过程中断您的程序员。
自动执行此过程:
如果没有对实际存储库进行第一次检入,则会更好。使它成为一个临时的,并使其构建。您可以选择执行性能测试,样式检查等,并将其包含在电子邮件中。如果您这样做,请向自动化流程添加一个步骤:
通过这种方式,慢速测试无关紧要。此外,当开发人员需要知道她的代码是否破坏了某些东西或者是否达到了预期的性能提升时,她只需检入并等待为她生成的电子邮件。
答案 4 :(得分:0)
我能想到的最好的方法是将所有依赖项放入一个“上下文”对象中,然后在所有实例之间共享。这应该会在一定程度上缓解性能问题。
答案 5 :(得分:0)
如果您的目标是.NET,请查看Autofac。它具有各种范围(单例,工厂,容器)来调整创建方面,确定性处理以保持资源使用,并允许使用GeneratedFactories和lambda表达式来配置组件并避免反射成本。