摘要：寫單元測試時，應該把這些依賴隔離，讓每個單元保持獨立。以上的各種原因，都會影響單元測試的結果。在單元測試的基礎上，將相關模塊組合成為子系統或系統進行測試，稱為集成測試。可以看到，單元測試速度比集成測試，也叫測試要快，并且開發成本也是最低。

原文鏈接：http://www.jianshu.com/p/bc99678b1d6e
作者：鍵盤男kkmike999

回顧：

《談談為什么寫單元測試》

Java單元測試框架：Junit、Mockito、Powermockito等；Android：Robolectric、AndroidJUnitRunner、Espresso等。

最開始建議先學習Junit & Mockito。這兩款框架是java領域應用非常普及，使用簡單，網上文章非常多，官網的說明也很清晰。junit運行在jvm上，所以只能測試純java，若要測試依賴android庫的代碼，可以用mockito隔離依賴（下面會談及）。

Junit官網
Mockito官網

之后學習AndroidJUnitRunner，Google官方的android單元測試框架之一，使用跟Junit是一樣的，只不過需要運行在android真機或模擬器環境。由于mockito只在jvm環境生效，而android是運行在Dalvik或ART，所以AndroidJUnitRunner不能使用mockito。

然后可以嘗試Robolectric & Espresso。Robolectric運行在jvm上，但是框架本身引入了android依賴庫，所以可以做android單元測試，運行速度比運行在真機or模擬器快。但Robolectric也有局限性，例如不支持加載so，測試代碼也有點別扭。當然，robolectric可以配合junit、mockito使用。Espresso也是Google官方的android單元測試框架之一，強大就不用說了，測試代碼非常簡潔。Espresso本身運行在真機上，因此android任何代碼都能運行，不像junit&mockito那樣隔離依賴。缺點也是顯而易見，由于運行在真機，不能避免“慢”。

Robolectric官網
Android-testing-support-library官網

其實espresso應該是幾款框架中最簡單的，但筆者還是建議先學習junit&mockito。因為新手很可能會因為espresso的強大、簡單，而忽略了junit做單元測試帶來的巨大意義。例如，前文提到“快速定位bug”、“提高代碼質量”，espresso慢，有違“快速”；用espresso不用修改工程任何代碼，這不利于提高代碼質量。

本文主要介紹junit和mockito，以及單元測試一些重要概念。

先給大家上兩段代碼壓壓驚：

public class Calculater {
    public int add(int a, int b) {
        return a + b;
    }
}

單元測試用例：

public class CalculaterTest {

    Calculater calculater = new Calculater();

    @org.junit.Test
    public void testAdd() {
        int a = 1;
        int b = 2;

        int result = calculater.add(a, b);

        Assert.assertEquals(result, 3); // 驗證result==3，如果不正確，測試不通過
    }
}

以上是一個要測試的類Calculater和測試用例CalculaterTest。在Intellij或Android Studio對類右鍵->run CalculaterTest，用例中所有被@org.junit.Test注解的方法，就會被執行。

測試通過。

如果代碼改成Assert.assertEquals(result, 4);，測試會失敗。

verify的作用，是驗證函數是否被調用（以及調用了多少次）。

public class CalculaterTest {

    @org.junit.Test
    public void testAdd2() {
        calculater = mock(Calculater.class);
        
        calculater.add(1, 2);

        verify(calculater).add(1, 2); // 驗證calculater.add(a, b)是否被調用過，且a==1 && b==2
        // 測試通過
    }
}

是不是很簡單？

官網這樣描述：

Mockito is a mocking framework that tastes really good. It lets you write beautiful tests with a clean & simple API.

大概意思是，Mockito是一個體驗很好的mocking框架，它可以讓你寫出漂亮、簡潔的測試代碼。

什么是mocking？下文會詳細說明。不如先讓你感受一下mockito代碼：

public interface IMathUtils {
    public int abs(int num); // 求絕對值
}

import static org.mockito.Mockito.mock;
import static org.mockito.Mockito.when;

public class MockTest {

    public static void main(String[] args) {
        IMathUtils mathUtils = mock(IMathUtils.class); // 生成mock對象

        when(mathUtils.abs(-1)).thenReturn(1); // 當調用abs(-1)時，返回1

        int abs = mathUtils.abs(-1); // 輸出結果 1
        
        Assert.assertEquals(abs, 1);// 測試通過
    }
}

可以發現IMathUtils是一個接口，根本就沒有實現，用Mockito框架mock之后，IMathUtils.abs(-1)就有返回值1了。這就是Mockito神奇的地方！Mockito代理了IMathUtils.abs(num)的行為，只要調用時符合指定參數（代碼中指定參數-1），就可以得到映射的返回值。

Mockito的語法when...thenReturn...相當直觀，只要你小學有學英語^_^都能看懂。

讀者肯定認為Mockito用了Java代理，實際上要更高級一點，Mockito底層用了CGLib（github/cglib）做動態代理。

依賴隔離，這是單元測試中一個非常重要的概念。一個單元的代碼，通常會有各種依賴。寫單元測試時，應該把這些依賴隔離，讓每個單元保持獨立。舉個例子：

public class Calculater {

    public double divide(int a, int b) {
        // 檢測被除數是否為0
        if (MathUtils.checkZero(b)) {
            throw new RuntimeException("dividend is zero");
        }

        return (double) a / b;
    }
}

public class MathUtils {
    public static boolean checkZero(int num) {
        return num == 0;
    }
}

divide(a,b)計算a除以b，但被除數b不應該為0，所以用MathUtils.checkZero(b)驗證b==0。咋看這里好像沒什么問題，但是，如果MathUtils.checkZero里面的判斷邏輯寫錯呢？例如：

 public static boolean checkZero(int num) {
    return  num != 0; // bug
 }

如果不是num==0那么簡單，而是更復雜的算法呢？

因為Calculater引用的任何依賴，都可能出錯。更糟糕的是，如果用junit做單元測試，依賴里面可能是Android庫或者jni native方法，依賴方法一執行就會報錯。以上的各種原因，都會影響單元測試的結果。所以，我們對代碼做如下改進：

public class Calculater {

    IMathUtils mathUtils;
    
    public double divide(int a, int b) {
        if (mathUtils.checkZero(b)) {
            throw ...
        }
        return (double) a / b;
    }
}

public interface IMathUtils {
    public boolean checkZero(int num);
}

我們可以在Calculater構造方法傳入IMathUtils派生類，又或者用setter。在項目執行代碼中，傳MathUtils，而單元測試時，可以寫一個MathUtilsTest繼承IMathUtils，傳給Calculater。只要保證MathUtilsTest.checkZero()正確就行。經過這么重構，Calculater 就不依賴原來的MathUtils，單元測試時可以替換專門的實現，達到了依賴隔離的目的。

有同學會問，這樣豈不是每個依賴都要寫一個專門給單元測試的類嗎？這就等于拷貝多一份代碼，并且寫各種接口，而且不能保證單元測試的類一定正確。

說得很有道理。筆者為了盡量簡單地演示代碼，舉了一個非常簡單的例子。我們如何讓單元測試更簡潔，并且讓它閱讀起來更有意義呢？

為了更好地解決上述問題，我們引入Mock概念。Mock，翻譯為模擬，在單元測試mock可以模擬返回數據，也可以模擬接口、類的行為。

什么是模擬行為？例如剛才mathUtils.checkZero(b)，意義為：“當mathUtils調用checkZero(num)”時，判斷 num==0；又或者：“當調用checkZero(0)時返回true，num為其他值時返回false”，返回的true、false就是模擬數據。

例如，需要測試a=2,b=1和a=2,b=0調用divide(a,b)兩者結果分別是2，拋出錯誤，使用mockito框架mock mathUtils.checkZero()的行為，代碼如下：

public static void main(String[] args) {
    // 生成IMathUtils模擬對象
    IMathUtils mathUtils = mock(IMathUtils.class);

    when(mathUtils.checkZero(1)).thenReturn(false); // 當num==1時，checkZero(num)返回false
    when(mathUtils.checkZero(0)).thenReturn(true); // 當num==0時，checkZero(num)返回true

    Calculater calculater = new Calculater(mathUtils);

    assertEquals(calculater.divide(2,1), 2); // 驗證 divide(2,1) 結果是2

    try {
        calculater.divide(2, 0); // 預期拋出錯誤
        throw new RuntimeException("no expectant exception"); // 如果divide沒拋錯，則此處拋錯
    } catch (Exception e) {
        Assert.assertEquals(e.getMessage(), "dividend is zero"); // 驗證錯誤信息
    }
}

這段測試代碼可以運行通過！

代碼剖析：

mock(IMathUtils.class)生成IMathUtils類的模擬對象(稱mock對象)。這個mock對象調用任何方法都不會被實際執行；

when(mathUtils.checkZero(1)).thenReturn(false)，當調用checkZero(num)并且num==1，返回false，這里mockito模擬了checkZero()行為，并模擬了返回數據；

所以，calculater.divide(2,1)返回結果2，calculater.divide(2, 0)拋出RuntimeException。

以上例子描述了，使用mockito模擬類方法和返回數據，通過mock隔離了Calculater對IMathUtils實現類的依賴，并通過單元測試，驗證了divide()的邏輯正確性。

要驗證程序正確性，必然要給出所有可能的條件（極限編程），并驗證其行為或結果，才算是100%覆蓋條件。實際項目中，驗證邊界條件和一般條件就OK了。

還是上面那個例子，只給出兩個條件：a=2,b=1和a=2,b=0，a=2,b=1是一般條件，b=0是邊界條件，還有一些邊界條件a=NaN，b=NaN等。要驗證除法正確性，恐怕得給出無限的條件，實際上，只要驗證幾個邊界條件和一般條件，基本認為代碼是正確了。

再舉個例子：stateA="a0"、"a1", stateB="b0"、"b1"、"b2"，根據stateA、stateB不同組合輸出不同結果，例如a0b0輸出a0b0，a0b1輸出a0b1，所以，共2*3=6種情況。這時，并不存在邊界條件，所以條件都是特定條件，并且條件有限。

這種情況在項目中很常見，以筆者經驗，建議單元測試時把所有情況都驗證一遍，確保沒有遺漏。

集成測試，也叫組裝測試、聯合測試。在單元測試的基礎上，將相關模塊組合成為子系統或系統進行測試，稱為集成測試。通俗一點，集成測試就是把多個（最少2個）組件合在一起，測試某個功能片段，甚至是多帶帶功能。

在微信群很多同學問：“用Robolectric能不能請求網絡”，"Junit能直接請求服務器嗎"？

例如，我們使用MVP模式，如果我們想測試：調用PresenterA接口，請求真實網絡，并且返回數據后，解析成對象，并且根據返回數據執行對應邏輯。這明顯就是一個集成測試，而不是單元測試。PresenterA是一個單元，M層的Repository、DAO等是一個單元，更底層的sqlite第三方庫、網絡請求第三方庫(okhttp等) 也是單元.....組合了n個單元的測試，是集成測試。

包括筆者在內，很多同學一開始都會有這個疑問。

閱讀了本文第一部分，應該了解到robolectric、junit是運行在jvm，只要有一點點java開發經驗的同學，都知道jvm本身能連接網絡。如果你調用的方法所依賴的一切代碼，都不依賴Android庫（例如okhttp、retrofit），那99%都能在jvm上跑，并且能請求服務器。如果不幸有Android依賴，很大概率還是能在robolectric上跑的。

為什么robolectric不是100%能跑通測試呢？Robolectric僅支持API21及以下，并且不支持jni庫。因此，如果你的代碼依賴了API21以上接口或者jni接口，robolectric也無能為力。天啊！怎么辦？

請讀者先不要沮喪，我們自有對策，不過要看讀者慧根了^_^！。前文“依賴隔離”提到，我們可以通過一定手段，把jni、android依賴隔離掉。咦？咱們的代碼是不是有救了？之后的文章，筆者會詳細給大家講解一下。

經過筆者指點，可能有讀者蠢蠢欲動去嘗試集成測試了.....且慢！說好的單元測試呢？集成測試看起來簡單，實際上由于依賴過多，很多時候很麻煩，而且運行慢；相比之下，單元測試則小巧、靈活得多，運行快，快速發現bug。在這方面，有一個理論Test Pyramid：

示意圖中，左箭頭表示速度，右箭頭表示開發成。可以看到，單元測試速度比集成測試（Service，也叫Integration）、UI測試要快，并且開發成本也是最低。Test Pyramid告訴我們，應該花大部分精力去寫單元測試，其次才是集成測試、UI測試。

筆者建議，還是先老老實實做單元測試，有時間精力再做集成測試。

本文介紹了幾個單元測試框架，介紹了junit、mockito初步使用，闡述了依賴隔離、mocking的概念，解答了"robolectric、junit能否請求網絡"問題。結合閱讀《談談為什么寫單元測試》，想必讀者對單元測試有了一個初步的了解。

如果讀者問筆者：“我的是小項目，是否有必要做單元測試？” 我很肯定地回答，任何項目都有必要做單元測試。至于單元測試是否耗費很多時間，或者效果不顯著，這要看使用者的編程經驗了，不能一概而論。

最后，叮囑讀者多敲代碼，真槍實彈地實踐單元測試。可以從公司項目小規模使用，形成自己單元測試風格后，就可以跟大范圍地推廣了。歡迎在本文留言討論！