在上一篇文章中，我們講了要將mock出來(lái)的dependency真正使用起來(lái)，需要在測(cè)試環(huán)境下通過(guò)某種方式set 到用到它的那個(gè)對(duì)象里面進(jìn)去，替換掉真實(shí)的實(shí)現(xiàn)。我們前面舉的例子是：
public class LoginPresenter {
private UserManager mUserManager = new UserManager();
public void login(String username, String password) {
//。。。some other code
mUserManager.performLogin(username, password);
}
}
在測(cè)試LoginPresenter#login()時(shí)，為了能夠?qū)ock出來(lái)的UserManager set到LoginPresenter里面，我們前面的做法是簡(jiǎn)單粗暴，給LoginPresenter加一個(gè)UserManager的setter。然而這種做法畢竟不是很優(yōu)雅，一般來(lái)說(shuō)，我們正式代碼里面是不會(huì)去調(diào)用這個(gè)setter，修改UserManager這個(gè)對(duì)象的。因此這個(gè)setter存在的意義就純粹是為了方便測(cè)試。這個(gè)雖然不是沒(méi)有必要，卻不是太好看，因此在有選擇的情況下，我們不這么做。在這里，我們介紹依賴注入這種模式。
對(duì)于依賴注入（Dependency Injection，以下簡(jiǎn)稱DI）的準(zhǔn)確定義可以在這里找到。它的基本理念這邊簡(jiǎn)單描述下，首先這是一種代碼模式，這個(gè)模式里面有兩個(gè)概念：Client和Dependency。假如你的代碼里面，一個(gè)類用到了另外一個(gè)類，那么前者叫Client，后者叫Dependency。結(jié)合上面的例子，LoginPresenter用到了UserManager，那么LoginPresenter叫Client，UserManager叫Dependency。當(dāng)然，這是個(gè)相對(duì)的概念，一個(gè)類可以是某個(gè)類的Dependency，卻是另外一個(gè)類的Client。比如說(shuō)如果UserManager里面用到了Retrofit，那么相對(duì)于Retrofit，UserManager又是Client。DI的基本思想就是，對(duì)于Dependency的創(chuàng)建過(guò)程，并不在Client里面進(jìn)行，而是由外部創(chuàng)建好，然后通過(guò)某種方式set到Client里面。這種模式，就叫做依賴注入。
是的，依賴注入就是這么簡(jiǎn)單的一個(gè)概念，這邊需要澄清的一點(diǎn)是，這個(gè)概念本身跟dagger2啊，RoboGuice這些框架并沒(méi)有什么關(guān)系?，F(xiàn)在很多介紹DI的文章往往跟dagger2是在一起的，因?yàn)閐agger2的使用相對(duì)來(lái)說(shuō)不是很直觀，所以導(dǎo)致很多人認(rèn)為DI是多么復(fù)雜的東西，甚至認(rèn)為只能用dagger等框架來(lái)實(shí)現(xiàn)依賴注入，其實(shí)不是這樣的。實(shí)現(xiàn)依賴注入很簡(jiǎn)單，dagger這些框架只是讓這種實(shí)現(xiàn)變得更加簡(jiǎn)單，簡(jiǎn)潔，優(yōu)雅而已。
DI的常見(jiàn)實(shí)現(xiàn)方式
下面介紹DI的實(shí)現(xiàn)方式，通常來(lái)說(shuō)，這里是大力介紹dagger2的地方。但是，雖然dagger2的確是非常好的東西，然而如果我直接介紹dagger2的話，會(huì)很容易導(dǎo)致一個(gè)誤區(qū)，認(rèn)為在測(cè)試的時(shí)候，也只能用dagger來(lái)做依賴注入或創(chuàng)建對(duì)應(yīng)的測(cè)試類，因此，我這邊刻意不介紹dagger。先讓大家知道最基本的DI怎么實(shí)現(xiàn)，然后在測(cè)試的時(shí)候如何更方便高效的使用。
實(shí)現(xiàn)DI這種模式其實(shí)很簡(jiǎn)單，有多種方式，上一篇文章中提到的setter，其實(shí)就是實(shí)現(xiàn)DI的一種方式，叫做 setter injection 。此外，通過(guò)方法的參數(shù)傳遞進(jìn)去（argument injection），也是實(shí)現(xiàn)DI的一種方式：
public class LoginPresenter {
//這里，LoginPresenter不再持有UserManager的一個(gè)引用，而是作為方法參數(shù)直接傳進(jìn)去
public void login(UserManager userManager, String username, String password) {
//... some other code
userManager.performLogin(username, password);
}
}
然而更常用的方式，是將Dependency作為Client的構(gòu)造方法的參數(shù)傳遞進(jìn)去：
public class LoginPresenter {
private final UserManager mUserManager;
//將UserManager作為構(gòu)造方法參數(shù)傳進(jìn)來(lái)
public LoginPresenter(UserManager userManager) {
this.mUserManager = userManager;
}
public void login(String username, String password) {
//... some other code
mUserManager.performLogin(username, password);
}
}
這種實(shí)現(xiàn)DI的模式叫 Constructor Injection。其實(shí)一般來(lái)說(shuō)，提到DI，指的都是這種方式。這種方式的好處是，依賴關(guān)系非常明顯。你必須在創(chuàng)建這個(gè)類的時(shí)候，就提供必要的dependency。這從某種程度上來(lái)說(shuō)，也是在說(shuō)明這個(gè)類所完成的功能。因此，盡量使用 Constructor injection。
說(shuō)到這里，你可能會(huì)有一個(gè)疑問(wèn)，如果把依賴都聲明在Constructor的參數(shù)里面，這會(huì)不會(huì)讓這個(gè)類的Constructor參數(shù)變得非常多？如果真的發(fā)生這種情況了，那往往說(shuō)明這個(gè)類的設(shè)計(jì)是有問(wèn)題的，需要重構(gòu)。為什么呢？我們代碼里面的類，一般可以分為兩種，一種是Data類，比如說(shuō)UserInfo，OrderInfo等等。另外一種是Service類，比如UserManager, AudioPlayer等等。所以這個(gè)問(wèn)題就有兩種情況了：
- 如果Constructor里面?zhèn)魅氲暮芏嗍腔绢愋偷臄?shù)據(jù)或數(shù)據(jù)類，那么或許你要做的，是創(chuàng)建一個(gè)（或者是另一個(gè)）數(shù)據(jù)類把這些數(shù)據(jù)封裝一下，這個(gè)過(guò)程的價(jià)值可是大大滴！而不僅僅是封裝一下參數(shù)的問(wèn)題，有了一個(gè)類，很多的方法就可以放到這個(gè)類里面了。這點(diǎn)請(qǐng)參考Martin Fowler的《重構(gòu)》第十章“Introduce Parameter Object”。
- 如果傳入的很多是service類，那么這說(shuō)明這個(gè)類做的事情太多了，不符合單一職責(zé)的原則（Single Responsibility Principle，SRP），因此，需要重構(gòu)。
接下來(lái)說(shuō)回我們的初衷：DI在測(cè)試?yán)锩娴膽?yīng)用。
DI在單元測(cè)試?yán)锩娴膽?yīng)用
所謂DI在單元測(cè)試?yán)锩娴膽?yīng)用，其實(shí)說(shuō)白了就是使用DI模式，將mock出來(lái)的Dependency set到Client里面去。我相信這篇文章解釋到這里，那么答案也就比較明顯了，為了強(qiáng)調(diào)我們要盡量使用 Constructor injection，對(duì)于 setter Injection 和 Argument injection 這邊就不做代碼示例了。
如果你的代碼使用的是 Constructor injection：
public class LoginPresenter {
private final UserManager mUserManager;
//將UserManager作為構(gòu)造方法參數(shù)傳進(jìn)來(lái)
public LoginPresenter(UserManager userManager) {
this.mUserManager = userManager;
}
public void login(String username, String password) {
//... some other code
mUserManager.performLogin(username, password);
}
}
其中我們要測(cè)的方法是login(), 要驗(yàn)證login()方法調(diào)用了mUserManager的performLigon()。對(duì)應(yīng)的測(cè)試方法如下：
public class LoginPresenterTest {
@Test
public void testLogin() {
UserManager mockUserManager = Mockito.mock(UserManager.class);
LoginPresenter presenter = new LoginPresenter(mockUserManager); //創(chuàng)建的時(shí)候，講mock傳進(jìn)去
presenter.login("xiaochuang", "xiaochuang password");
Mockito.verify(mockUserManager).performLogin("xiaochuang", "xiaochuang password");
}
}
很簡(jiǎn)單，對(duì)吧。
小結(jié)
這篇文章介紹了DI的概念，以及在單元測(cè)試?yán)锩娴膽?yīng)用，這里特意沒(méi)有介紹dagger2的使用，目的是要強(qiáng)調(diào)：
- 一個(gè)靈活的，易于測(cè)試的，符合SRP的，結(jié)構(gòu)清晰的項(xiàng)目，關(guān)鍵在于要應(yīng)用依賴注入這種模式，而不是用什么來(lái)做依賴注入。
- 等你學(xué)會(huì)使用dagger以后，要記得在測(cè)試的時(shí)候，如果可以直接mock dependency并傳給被測(cè)類，那就直接創(chuàng)建，不是一定要使用dagger來(lái)做DI
然而如果完全不使用框架來(lái)做DI，那么在正式代碼里面就有一個(gè)問(wèn)題了，那就是dependency的創(chuàng)建工作就交給上層client去處理了，這可不是件好事情。想想看，LoginActivity里面創(chuàng)建LoginPresenter的時(shí)候，還得知道LoginPresenter用了UserManager。然后創(chuàng)建一個(gè)UserManager對(duì)象給LoginPresenter。對(duì)于LoginActivity來(lái)說(shuō)，它覺(jué)得我才懶得管你用什么樣的UserManager呢，我只想告訴你login的時(shí)候，你給我老老實(shí)實(shí)的login就好了，你用什么Manager我不管。所以，直接在LoginActivity里面創(chuàng)建UserManager，可能不是個(gè)好的選擇。那怎么樣算是一個(gè)好的選擇呢？dagger2給了我們答案。
于是下一篇文章我們介紹dagger2。
文中的代碼在github這個(gè)項(xiàng)目里面。
最后，如果你對(duì)安卓單元測(cè)試感興趣，歡迎加入我們的交流群，因?yàn)槿撼蓡T超過(guò)100人，沒(méi)辦法掃碼加入，請(qǐng)關(guān)注下方公眾號(hào)獲取加入方法。
