使用DI的最大优点之一是使测试变得更加容易(什么是依赖注入? 也支持这个观点)。我曾经在其他编程语言上使用过大多数DI框架(.NET上的MEF,Obj-C/Swift上的Typhoon,PHP上的Laravel IoC容器等),它们允许开发者为每个组件在单个入口点注册依赖项,从而防止对象本身“创建”依赖项。
在我阅读Dagger 2文档后,整个“无反射”业务听起来很棒,但我无法看到它如何使测试变得更容易,因为对象仍然会自己创建依赖项。
例如,在CoffeMaker示例中:
即使您没有显式调用
现在让我们来看一个更详细的例子,转到 Android Example。 如果您打开
在我阅读Dagger 2文档后,整个“无反射”业务听起来很棒,但我无法看到它如何使测试变得更容易,因为对象仍然会自己创建依赖项。
例如,在CoffeMaker示例中:
public class CoffeeApp {
public static void main(String[] args) {
// THIS LINE
CoffeeShop coffeeShop = DaggerCoffeeShop.create();
coffeeShop.maker().brew();
}
}
即使您没有显式调用
new
,您仍然必须创建您的依赖项。现在让我们来看一个更详细的例子,转到 Android Example。 如果您打开
DemoActivity
类,您会注意到 onCreate
实现如下:@Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
// Perform injection so that when this call returns all dependencies will be available for use.
((DemoApplication) getApplication()).component().inject(this);
}
您可以清楚地看到,从 DI 组件到实际代码并没有解耦。简而言之,在测试用例中需要模拟/存根 ((DemoApplication) getApplication()).component().inject(this);
(如果可能的话)。
到目前为止,我知道 Dagger 2 很受欢迎,所以肯定有我没有注意到的东西。那么 Dagger 2 如何使测试类更容易?我将如何模拟,比方说一个与我的 Activity 相关联的网络服务类? 我希望答案尽可能简单,因为我只关心测试。
@Provides
注释,就可以覆盖模块。 - EpicPandaForce