在我的分析器报告中,我越来越多地看到依赖注入的基于模拟的测试结果.许多依赖项都是静态的,但是因为我们想要单独测试方法,所以它们会更改为实例成员,如下例所示：
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();
}
}
反过来,依赖关系大部分时间都有其他依赖关系,依此类推.每次在测试之外进行方法调用时,这导致(实际上是“静态”)对象树的实例化.每个对象都非常小(只有几个指针),但树效果将其变为不断增加的性能.
我们对于它可以做些什么呢？
在我看来,您需要利用适当的依赖注入框架可以为您提供的功能.不要使用不同的构造逻辑进行测试/生产.
对于弹簧,单次注射仅在容器启动时执行.每次都进行原型注射.每次运行单元测试时,如果正在连接,也会完成全部接线.所以剖析单元测试通常不是一个好主意.
也许你使用的单例范围太少,原型范围太多？ (每次原型=新实例)
弹簧注入的好处是你可以使用范围代理,这意味着你的对象图可能如下所示：
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模型中创建最小的对象.
