作者：ZeusL

團隊：騰訊移動品質中心TMQ

一、單元測試及Android單元測試簡介

慣例，先簡單介紹下理論知識，懂得的可以跳過。

1、單元測試定義和特性

單測定義：

在計算機程式設計中，單元測試（Unit Testing）又稱為模組測試, 是針對程式模組（軟體設計的最小單位）來進行正確性檢驗的測試工作。
程式單元是應用的最小可測試部件。在過程化程式設計中，一個單元就是單個程式、函式、過程等；對於面向物件程式設計，最小單元就是方法，包括基類（超類）、抽象類、或者派生類（子類）中的方法。

單測特性：

擷取下《單元測試的藝術》一書中的優秀的單元測試特性，牢記！

2、Android單元測試

顧名思義，是在Android系統下進行的單元測試。

業界上已經有很多工具可以支援做Android系統下的單元測試，主要分為兩大類：

（1）Instrumentation

通過Android系統的Instrumentation測試框架，我們可以編寫測試程式碼，並且打包成APK，執行在Android手機上。

優點： 逼真；

缺點： 很慢；

代表框架：Junit,Espresso。

（2）Junit / Mock

通過Junit，以及第三方測試框架，我們可以編寫測試程式碼，生成class檔案，直接執行在JVM虛擬機器中。

優點： 很快，使用簡單，方便；

缺點： 不夠逼真，比如有些硬體相關的問題，無法通過這些測試出來；

代表框架： Junit,Robolectric, Mockito, Powermock。

Robolectric：一個單元測試框架，可以清除Android SDK(通過shadow技術)，以便您可以測試驅動Android應用程式的開發，測試JVM內部執行，用例執行速度很快。

Espresso：一種簡潔，美觀，可靠的Android UI測試框架。

Mockito：一個針對 Java 的單元測試模擬框架，它與 EasyMock 和 jMock 很相似，都是為了簡化單元測試過程中測試上下文 ( 或者稱之為測試驅動函式以及樁函式 ) 的搭建而開發的工具。

Powermock：是在 EasyMock 以及 Mockito 基礎上的擴充套件，通過定製類載入器等技術，實現了之前提到的所有Mockito不能模擬的功能,比如靜態函式、建構函式、私有函式、Final 函式以及系統函式的模擬。

二、Google官方MVP架構

在熟悉單元測試框架前，首先需要學習了下Google官方推薦Android的MVP專案架構，好的框架單元測試也比較好開展。

其推薦的專案中MVP各層所使用的單元測試框架如下圖所示：

其MVP測試架構圖總結如下：

專案程式碼有興趣學習的同學可以去自行下載去學習，學習這種優秀程式碼是最快的方式。

View層：

職責：MVP模式下，View本身該做的事情都能做了，比如UI佈局，資料渲染，點選按鈕互動等等。

測試方式：以正常小QA的測試思維方法，就可以來定義這一層的測試方式，測試過程中需要真機或模擬器，並做真實的操作。

測試選型：依賴於Android環境，用谷歌強大的Espresso+AndroidJunitRunner，Espresso用於模擬和驗證各種各樣的UI操作，程式碼存放於AndroidTest中。

Presenter層：

職責：這一層是拉皮條的，負責M和V層的對接，所以有較少的處理輸入輸出的機會，他只用來控制邏輯，去呼叫相應的Model和View的邏輯。

測試選型：他的職責決定了他很少去斷言輸入輸出，測試邏輯覆蓋的路徑是否正確即可，因此他與Android環境無關，用Junit+Mockito測試即可，程式碼存放於test中。

Model層：

職責：負責資料的存取，資料可能來自於網路、資料庫和記憶體。

資料庫增刪改查：需測試資料存取的準確性，依賴Android環境進行測試，因此使用AndroidJunitRunner，程式碼存放於AndroidTest中。

網路請求：不測試真實的網路請求，但提供了Fake供其他層呼叫測試。

封裝的門面類：決定了資料的來源和去向是來自於本地資料庫 or 網路 or 記憶體，此為真正對其他層暴露的Model類。此類不做資料準確性的驗證，只做mock測試，驗證覆蓋路徑。UT選型Junit+Mockito，程式碼存放於test中。

MVP各個模組通訊方式如下：

除了MVP，還有一種MVC的方式。

MVC的全稱為Model-View-Controller，即模型-檢視-控制器。

Model：處理資料和業務邏輯等。

View：顯示介面，展示結果等。

Controller：控制流程，處理互動。

MVC各個模組通訊方式如下：

MVC和MVP區別：

在MVC模式中，View和Model可以直接互動；在MVP模式中，View和Model模組不能直接互動，View通過Presenter與Model間接互動。

在MVC中，Controller是基於行為的，可以被多個View共享，可以負責決定顯示哪個View；在MVP中View和Presenter是一對一或這一對多的，並且Presenter和View是通過介面互動的。

三、單元測試環境一些基本的準備工作

1、新建一個標準的Android Studio工程

新建一個andriod Studio工程，這個就不詳細說明了，網上有很多教程。

成功後src目錄下就出現AndroidTest和test下目錄。

2、原始碼和其他工程目錄搬遷移植

將原始碼目錄全部放在src/main/java下（適合老業務改造）。

如果原始碼目錄指定不對，需要修改build.Gradle的sourceSets配置。

3、增加工具框架依賴

在dependencies下增加工具框架的引用。

注：如果用到什麼框架就將框架引用進來即可，但有些工具主要版本號的相互搭配，不匹配可能會出現錯誤。

網上有一個PowerMock對Mockito的版本對應關係：

作者使用的是下面紅色的組合，請根據實際情況匹配。

4、增加Jacoco覆蓋率

增加Jacoco的外掛：

指定版本號和報告目錄：

指定原始碼目錄。
自定義Jacoco報告規則task：

上面一切準備完畢後，配置好程式碼，Gradle就可以正常同步載入了。

如果你的Android Studio的Gradle Sync同步成功，那麼恭喜你單測環境基本OK了，依賴庫基本也已經下載完畢，下面可以愉快的開始著手程式碼編寫了。

可能有的公司需要網路代理，那這個需要根據具體情況在Gradle中配置了。

四、編寫AndroidTest下的單測用例

UI層的單元測試只簡單介紹一下，作者實際編寫單元測試的時候，UI部分的單元測試用例也是放在了test目錄下一起寫的(PowerMock模擬的)，執行不需要手機或模擬器，執行速度比較快。

雖然沒有在實際專案中大量使用，但也將當初的嘗試簡單介紹一下，供參考。

UI的Instrumentation用例可以選取Espresso。

在AndroidTest目錄下新建一個測試類。

比如我們測試一個這樣的單測用例：測試更新頁的點選更新所有，使用者頁面會彈出一個toast確認的彈框。

用例編寫如下：

手機連上電腦，選中用例滑鼠右鍵run就可以執行看結果了。

五、編寫test下的單元測試用例

首先介紹下單測工具框架選取的過程。

1、選取合適的測試框架

作者開始在業務中嘗試使用Robolectric測試框架，初心主要在於他的特性：

Robolectric Test-Drive Your Android Code Running tests on an Android emulator or device is slow! Building, deploying, and launching the app often takes a minute or more. That’s no way to do TDD. There must be a better way.
Wouldn’t it be nice to run your Android tests directly from inside your IDE? Perhaps you’ve tried, and been thwarted by the dreaded java.lang.RuntimeException: Stub!?

它不需要Run你的模擬器，直接在jvm上執行你的測試程式碼，能在短時間之內快速驗證，通過體驗之後，它確實非常高效，編寫測試程式碼反而加速了開發效率。

另外被它強大的Shadows方式所吸引，可以完全實現自定義方式。

但在實際使用的過程中遇到了不少的坑，比如：

Robolectric版本和SDK版本強依賴。

compileSdkVersion 23的不能使用Robolectric:3.0的版本，只能使用Robolectric:3.2.2以上的。為什麼會有這種強依賴，是因為Robolectric會shadow大部分Android的程式碼，會有很多shadow的類，也就會隨sdk版本的變化而變化。

Robolectric首次啟動下載maven相關的依賴失敗。

即使我們在開發網下設定了代理，開通外網許可權，首次啟動還會去下載相關依賴，結果是下載失敗，這個是由於Robolectric本身程式碼裡的邏輯，我們不能通過網路代理的方式解決。

唯一的辦法只能一個一個手工的下載後丟到你的.m2\repository\org\Robolectric目錄下，讓Robolectric找到其所依賴的jar包，不需要在去下載，如下：

如果在build.Gradle重新指定Robolectric的版本，那麼這些需要的版本還要手工下載一遍。

Robolectric執行報TinkerRuntimeException: Tinker Exception:onCreate method not found
業務使用了Tinker多包載入架構，執行出現上面的異常。

解決方法：
RealAstApp裡面人為增加oncreate方法
@Override
public void onCreate() {
}
這樣修改程式碼其實是有點犯忌的，但只改這一處還勉強可以接受，下面的就不能接受了。

Robolectric執行在自定義的控制元件時有時會出現xml解析異常。
跟蹤解決了幾個，發現要修改的地方比較多，這裡省略一萬字的修改記錄。
除了改動點比較多，也可能後續會出現更多的潛在錯誤。
違背上面的單元測試特性之執行穩定，衡量再三，還是決定放棄Robolectric了，另尋它徑。

這裡也宣告下，Robolectric工具還是很優秀的，它的解決思路很清晰，所有呼叫到Android相關的都會轉移到其shadow類，這樣就可以完全脫離Android的限制，只是由於業務的特殊性才暫時不用。

於是又開始研究Espresso，見上面的(編寫AndroidTest單元測試用例)。
使用過程中總體感覺Espresso功能比較強大，只要合理的使用其提供的api和matches規則，常用的UI邏輯基本都可以模擬，但唯一不爽的就是每次都要連線手機或者模擬器才能執行，Run的過程中，首先會打包，部署到手機上，然後再開始一個一個執行測試用例，好處是手機上的表現很直觀，但這樣除錯和執行速度是真心的慢。

違背上面的單元測試特性之執行速度快，建議放棄。

嘗試使用Junit、Mockito和Powermock來編寫MVP三層的單元測試用例，在經過一陣探索後，MVP三層的邏輯基本都可以通過Mockito和Powermock來模擬出來，執行起來關鍵是速度快，速度快，速度快，好的地方說三遍。

上面的單元測試特性也基本都能滿足，最終決定使用Junit、Mockito和Powermock這個框架組合來進行我們的單元測試用例設計和編寫。

2、選取被測模組和熟悉被測模組的程式碼邏輯

在單元測試前要對被測模組有個大致的程式碼邏輯熟悉，對程式碼的深入可以邊寫邊熟悉。

3、PowerMock知識點掌握

單測用例編寫過程中，熟練程度一部分完全取決於對單測工具框架的瞭解程度，這塊沒捷徑可走，必須要掌握清楚明白，簡單列一下其知識點，具體還是需要自己去搜索資料掌握的。

（1）PowerMock註解@RunWith與@PrepareForTest的使用；

（2）測試或模擬static方法；

（3）測試或模擬返回void的靜態方法；

（4）PowerMockito.doNothing與PowerMockito.doThrow的使用；

（5）如何驗證方法呼叫；

（6）如何驗證呼叫次數的方法；

（7）測試或模擬final類或方法；

（8）測試或模擬構造方法；

（9）如何做引數匹配；

（10）Answer介面的使用；

（11）如何使用spy進行部分模擬；

（12）如何測試或模擬私有方法；

（13）@Before和@Test的作用；

（14）如何給私有的欄位賦值；

（15）如何模擬異常。

4、設計單元測試用例

需要寫單測case列表。

在我們的專案中，單元測試物件建議和類相對應，這樣的單元測試結果比較直觀。單元測試分析被測類的業務邏輯，這裡的邏輯不僅僅包括介面元素的展示以及控制元件元件的行為，還包括程式碼的處理邏輯。然後可以建立單元測試case列表，列表用於紀錄專案中單元測試的範圍，便於單元測試的管理以及新人瞭解業務流程，列表中記錄單元測試物件的頁面，物件中的case邏輯以及名稱等，測試或開發工程師可以根據這個列表開始寫單元測試程式碼。

用覆蓋率來校驗單測用例是否完備。

單元測試是工程師程式碼級別的質量保證工程，上述流程並不能完全覆蓋重要的業務邏輯以及邊界條件，因此，需要寫完後，看覆蓋率，找出單元測試中沒有覆蓋到的函式分支條件等，然後繼續補充單元測試case列表，並在單元測試工程程式碼中補上case。

直到被測類所有邏輯的重要分支、邊界條件都被覆蓋，才認為該類的單元測試結束。

另外覺得複用或通用的邏輯建議做成工具類，直接複用。

整理了一個case的單測流程圖，供參考：

5、公共的可複用的抽離出成工具類

將一些常用的場景抽象出工具mock類，如BundleMock、HandlerMock、IntentMock、MainThreadHandler、ParcelMock等等，這樣提供給單測直接呼叫即可，不用在重複造車輪。

6、幾種場景的單元測試用例案例

單元測試用例設計，格式可以自己靈活去定義，另外也可以在程式碼中已Javadoc的方式新增單元測試用例內容，輸入、輸出、斷言幾點明確就可以了。
我們把一部分專案常用的場景通過mock實現後，剩下的基本都是工作量的問題了。

目前業務程式碼邏輯場景的模擬做了如下：

（1）請求的模擬及回撥onRequestSuccessed和onRequestFailed的模擬；

（2）頁面inflate載入場景模擬；

（3）頁面findViewById載入場景模擬；

（4）控制元件onclick場景模擬；

（5）資料回撥場景模擬；

（6）主執行緒handler場景模擬；

（7）序列化的模擬；

（8）intent的模擬；

（9）其他等等。

這部分的模擬程式碼就不貼上來了，有點多，需要可以線下交流。

7、單測類的編寫經驗

（1）mock物件可以被整個類的測試方法共用的，mock時統一放到@Before裡init；

（2）mock物件僅供單個單測用例使用的，mock時可以直接放到單測用例裡；

（3）能抽象出來的mock物件，建議做成工具類呼叫；

（4）單測用例一定要有斷言，且斷言準確，這樣才能保證單測用例的有效性；

（5）不要怕麻煩，開始都會感覺很難，寫多了熟練了就好了。

8、debug除錯

執行時候如何出現一堆黃色的PASSED，心裡當然感覺爽了。

但在單元測試編寫執行中難免會出現各種異常錯誤，mock時出現空指標的場景會比較多，這時候我們就需要用debug除錯方式。

然後設定斷點，通過F8逐步跟蹤下去吧，找出單測用例的編寫的問題所在。

9、生成覆蓋率報告

在Android Studio的Terminal中輸入Gradlew JacocoTestReport後，單元測試開始執行，無錯誤結束後就會在指定的報告生成目錄下看到覆蓋率結果了。

通過覆蓋率結果，檢視到單測case覆蓋情況，根據情況補充或修改單測用例，加大覆蓋率結果的提升，單測是有望達到100%覆蓋的。

單測過程中可能會出現某些類的覆蓋率結果為0的，但實際上應該有覆蓋率的，這可能是由於一些頁面單測場景下被測類在@PrepareForTest中聲明瞭，導致這些類的覆蓋率為0。以前作者也介紹過Jacoco的原理，其是修改class位元組碼檔案插樁的，但再經過PrepareForTest這種指定後，PowerMock也會修改class的位元組碼，這樣就把Jacoco的插樁沖掉了，導致覆蓋率為0，這部分我們可以通過自己寫指令碼的方式來算覆蓋率，然後在和Jacoco的覆蓋率相疊加算出總的覆蓋率。

六、做單測的意義

現在各個專案的程式碼量都比較龐大，全部進行單測覆蓋，工作量消耗是非常巨大的。

並且產出和收益也不一定成正比例。

其實我們做單測和做系統測試的出發點都是一樣的，提升專案的總體質量。

兩點實施方式：

1、對於開發久，穩定的功能，單測的出發點為系統功能測試的互補。

單測的著重點在功能測試難覆蓋的地方，通過單測發現功能測試難發現的問題及程式碼潛在的問題。

2、對應剛開發，新功能，如果有時間和人力的話，可以考慮單測全覆蓋。

儘量在開發編碼時並行實施，或者推動開發自己寫單測。

最後有一個話題有機會大家可以一起討論下：

單測的投入和產出如何來平衡？

獲取更多測試相關乾貨 請關注我們的微信公眾號——騰訊移動品質中心TMQ：