在上一篇文章中&＃xff0c;咱们讲了要将mock出来的dependency真正使用起来&＃xff0c;须要在测试环境下经过某种方式set 到用到它的那个对象里面进去&＃xff0c;替换掉真实的实现。咱们前面举的例子是&＃xff1a;html
public class LoginPresenter {
private UserManager mUserManager &＃61; new UserManager();
public void login(String username, String password) {
//。。。some other code
mUserManager.performLogin(username, password);
}
}
在测试LoginPresenter#login()时&＃xff0c;为了可以将mock出来的UserManager set到LoginPresenter里面&＃xff0c;咱们前面的作法是简单粗暴&＃xff0c;给LoginPresenter加一个UserManager的setter。然而这种作法毕竟不是很优雅&＃xff0c;通常来讲&＃xff0c;咱们正式代码里面是不会去调用这个setter&＃xff0c;修改UserManager这个对象的。所以这个setter存在的意义就纯粹是为了方便测试。这个虽然不是没有必要&＃xff0c;却不是太好看&＃xff0c;所以在有选择的状况下&＃xff0c;咱们不这么作。在这里&＃xff0c;咱们介绍依赖注入这种模式。java
对于依赖注入(Dependency Injection&＃xff0c;如下简称DI)的准肯定义能够在这里找到。它的基本理念这边简单描述下&＃xff0c;首先这是一种代码模式&＃xff0c;这个模式里面有两个概念&＃xff1a;Client和Dependency。假如你的代码里面&＃xff0c;一个类用到了另一个类&＃xff0c;那么前者叫Client&＃xff0c;后者叫Dependency。结合上面的例子&＃xff0c;LoginPresenter用到了UserManager&＃xff0c;那么LoginPresenter叫Client&＃xff0c;UserManager叫Dependency。固然&＃xff0c;这是个相对的概念&＃xff0c;一个类能够是某个类的Dependency&＃xff0c;倒是另一个类的Client。好比说若是UserManager里面用到了Retrofit&＃xff0c;那么相对于Retrofit&＃xff0c;UserManager又是Dependency。DI的基本思想就是&＃xff0c;对于Dependency的建立过程&＃xff0c;并不在Client里面进行&＃xff0c;而是由外部建立好&＃xff0c;而后经过某种方式set到Client里面。这种模式&＃xff0c;就叫作依赖注入。android
是的&＃xff0c;依赖注入就是这么简单的一个概念&＃xff0c;这边须要澄清的一点是&＃xff0c;这个概念自己跟dagger2啊&＃xff0c;RoboGuice这些框架并无什么关系。如今不少介绍DI的文章每每跟dagger2是在一块儿的&＃xff0c;由于dagger2的使用相对来讲不是很直观&＃xff0c;因此致使不少人认为DI是多么复杂的东西&＃xff0c;甚至认为只能用dagger等框架来实现依赖注入&＃xff0c;其实不是这样的。实现依赖注入很简单&＃xff0c;dagger这些框架只是让这种实现变得更加简单&＃xff0c;简洁&＃xff0c;优雅而已。git
DI的常见实现方式
下面介绍DI的实现方式&＃xff0c;一般来讲&＃xff0c;这里是大力介绍dagger2的地方。可是&＃xff0c;虽然dagger2的确是很是好的东西&＃xff0c;然而若是我直接介绍dagger2的话&＃xff0c;会很容易致使一个误区&＃xff0c;认为在测试的时候&＃xff0c;也只能用dagger来作依赖注入或建立对应的测试类&＃xff0c;所以&＃xff0c;我这边刻意不介绍dagger。先让你们知道最基本的DI怎么实现&＃xff0c;而后在测试的时候如何更方便高效的使用。github
实现DI这种模式其实很简单&＃xff0c;有多种方式&＃xff0c;上一篇文章中提到的setter&＃xff0c;其实就是实现DI的一种方式&＃xff0c;叫作 setter injection 。此外&＃xff0c;经过方法的参数传递进去(argument injection)&＃xff0c;也是实现DI的一种方式&＃xff1a;框架
public class LoginPresenter {
//这里&＃xff0c;LoginPresenter再也不持有UserManager的一个引用&＃xff0c;而是做为方法参数直接传进去
public void login(UserManager userManager, String username, String password) {
//... some other code
userManager.performLogin(username, password);
}
}
然而更经常使用的方式&＃xff0c;是将Dependency做为Client的构造方法的参数传递进去&＃xff1a;单元测试
public class LoginPresenter {
private final UserManager mUserManager;
//将UserManager做为构造方法参数传进来
public LoginPresenter(UserManager userManager) {
this.mUserManager &＃61; userManager;
}
public void login(String username, String password) {
//... some other code
mUserManager.performLogin(username, password);
}
}
这种实现DI的模式叫 Constructor Injection。其实通常来讲&＃xff0c;提到DI&＃xff0c;指的都是这种方式。这种方式的好处是&＃xff0c;依赖关系很是明显。你必须在建立这个类的时候&＃xff0c;就提供必要的dependency。这从某种程度上来讲&＃xff0c;也是在说明这个类所完成的功能。所以&＃xff0c;尽可能使用 Constructor injection。测试
说到这里&＃xff0c;你可能会有一个疑问&＃xff0c;若是把依赖都声明在Constructor的参数里面&＃xff0c;这会不会让这个类的Constructor参数变得很是多&＃xff1f;若是真的发生这种状况了&＃xff0c;那每每说明这个类的设计是有问题的&＃xff0c;须要重构。为何呢&＃xff1f;咱们代码里面的类&＃xff0c;通常能够分为两种&＃xff0c;一种是Data类&＃xff0c;好比说UserInfo&＃xff0c;OrderInfo等等。另一种是Service类&＃xff0c;好比UserManager, AudioPlayer等等。因此这个问题就有两种状况了&＃xff1a;ui
若是Constructor里面传入的不少是基本类型的数据或数据类&＃xff0c;那么或许你要作的&＃xff0c;是建立一个(或者是另外一个)数据类把这些数据封装一下&＃xff0c;这个过程的价值但是大大滴&＃xff01;而不只仅是封装一下参数的问题&＃xff0c;有了一个类&＃xff0c;不少的方法就能够放到这个类里面了。这点请参考Martin Fowler的《重构》第十章“Introduce Parameter Object”。this
若是传入的不少是service类&＃xff0c;那么这说明这个类作的事情太多了&＃xff0c;不符合单一职责的原则(Single Responsibility Principle&＃xff0c;SRP)&＃xff0c;所以&＃xff0c;须要重构。
接下来讲回咱们的初衷&＃xff1a;DI在测试里面的应用。
DI在单元测试里面的应用
所谓DI在单元测试里面的应用&＃xff0c;其实说白了就是使用DI模式&＃xff0c;将mock出来的Dependency set到Client里面去。我相信这篇文章解释到这里&＃xff0c;那么答案也就比较明显了&＃xff0c;为了强调咱们要尽可能使用 Constructor injection&＃xff0c;对于 setter Injection 和 Argument injection 这边就不作代码示例了。
若是你的代码使用的是 Constructor injection&＃xff1a;
public class LoginPresenter {
private final UserManager mUserManager;
//将UserManager做为构造方法参数传进来
public LoginPresenter(UserManager userManager) {
this.mUserManager &＃61; userManager;
}
public void login(String username, String password) {
//... some other code
mUserManager.performLogin(username, password);
}
}
其中咱们要测的方法是login(), 要验证login()方法调用了mUserManager的performLigon()。对应的测试方法以下&＃xff1a;
public class LoginPresenterTest {
&＃64;Test
public void testLogin() {
UserManager mockUserManager &＃61; Mockito.mock(UserManager.class);
LoginPresenter presenter &＃61; new LoginPresenter(mockUserManager); //建立的时候&＃xff0c;讲mock传进去
presenter.login("xiaochuang", "xiaochuang password");
Mockito.verify(mockUserManager).performLogin("xiaochuang", "xiaochuang password");
}
}
很简单&＃xff0c;对吧。
小结
这篇文章介绍了DI的概念&＃xff0c;以及在单元测试里面的应用&＃xff0c;这里特地没有介绍dagger2的使用&＃xff0c;目的是要强调&＃xff1a;
一个灵活的&＃xff0c;易于测试的&＃xff0c;符合SRP的&＃xff0c;结构清晰的项目&＃xff0c;关键在于要应用依赖注入这种模式&＃xff0c;而不是用什么来作依赖注入。
等你学会使用dagger之后&＃xff0c;要记得在测试的时候&＃xff0c;若是能够直接mock dependency并传给被测类&＃xff0c;那就直接建立&＃xff0c;不是必定要使用dagger来作DI
然而若是彻底不使用框架来作DI&＃xff0c;那么在正式代码里面就有一个问题了&＃xff0c;那就是dependency的建立工做就交给上层client去处理了&＃xff0c;这可不是件好事情。想一想看&＃xff0c;LoginActivity里面建立LoginPresenter的时候&＃xff0c;还得知道LoginPresenter用了UserManager。而后建立一个UserManager对象给LoginPresenter。对于LoginActivity来讲&＃xff0c;它以为我才懒得管你用什么样的UserManager呢&＃xff0c;我只想告诉你login的时候&＃xff0c;你给我老老实实的login就行了&＃xff0c;你用什么Manager我无论。因此&＃xff0c;直接在LoginActivity里面建立UserManager&＃xff0c;可能不是个好的选择。那怎么样算是一个好的选择呢&＃xff1f;dagger2给了咱们答案。
因而下一篇文章咱们介绍dagger2。
最后&＃xff0c;若是你也对安卓单元测试感兴趣的话&＃xff0c;欢迎加入咱们的交流群&＃xff1a;
京公网安备 11010802041100号