前言

在專案開發過程中必不可少的會用到測試框架來檢查自己的程式碼邏輯，可能大多數人和我一樣從來沒有怎麼重視過測試程式碼，認為測試程式碼存在與否的意義不大。但是，看過很多大牛的專案後，發現他們寫的專案中測試用例的程式碼遠多於實際程式碼。所以，為了向大牛們看齊，最近又重新學習了一波之前用到過的測試框架，在這裡做一個小結。

1. 常見測試框架

我在專案開發過程中使用的單元測試框架有Junit、TestNG以及Mockito,Junit和TestNG使用的比較多，Mockito最近才開始使用。對於Junit和TestNG的用法我就不多做介紹了，相信大家都會使TestNG和JUnit是針對Java語言的兩個比較常用的測試框架。JUnit出現的比較早，但是早期的JUnit 3對測試程式碼有非常多的限制，使用起來很不方便，後來的JUnit 4得到很大的改進。TestNG的出現介於JUnit 3和JUnit 4，但是TestNG在很多方面還要優於JUnit 4。下面從整體上對TestNG和JUnit 4進行比較全面的比較。

TestNG與JUnit的相同點
1. 使用annotation，且大部分annotation相同。
2. 都可以進行單元測試（Unit test）。
3. 都是針對Java測試的工具。

TestNG與JUnit的不同點：
1. JUnit只能進行單元測試，TestNG可以進行單元測試，功能測試，端到端測試，整合測試等。
2. TestNG需要一個額外的xml配置檔案，配置測試的class、method甚至package。
3. TestNG的執行方式更加靈活：命令列、ant和IDE，JUnit只能使用IDE。
4. TestNG的annotation更加豐富，比如@ExpectedExceptions、@DataProvider等。
5. 測試套件執行失敗，JUnit 4會重新執行整個測試套件。TestNG執行失敗時，會建立一個XML檔案說明失敗的測試，利用這個檔案執行程式，就不會重複執行已經成功的測試。

TestNG比JUnit 4靈活性的體現：
1. JUnit 4中必須把@BeforeClass修飾的方法宣告為public static，這就限制了該方法中使用的變數必須是static。而TestNG中@BeforeClass修飾的方法可以跟普通函式完全一樣。
2. JUnit 4測試的依賴性非常強，測試用例間有嚴格的先後順序。前一個測試不成功，後續所有的依賴測試都會失敗。TestNG 利用@Test 的dependsOnMethods屬性來應對測試依賴性問題。某方法依賴的方法失敗，它將被跳過，而不是標記為失敗。
3. 對於n個不同引數組合的測試，JUnit 4要寫n個測試用例。每個測試用例完成的任務基本是相同的，只是受測方法的引數有所改變。TestNG的引數化測試只需要一個測試用例，然後把所需要的引數加到TestNG的xml配置檔案中。這樣的好處是引數與測試程式碼分離，非程式設計師也可以修改引數，同時修改無需重新編譯測試程式碼。
4. JUnit 4的測試結果通過Green/Red bar體現，TestNG的結果除了Green/Red bar，還有test-output資料夾，對測試結果的描述更加詳細，方便定位錯誤。

相比於Junit和TestNG,mockito的功能是解決units之間由於耦合而難於被單獨測試的問題，下面做下簡單介紹，具體的用法請參照http://site.mockito.org/

什麼是mock？
在軟體開發的世界之外, “mock”一詞是指模仿或者效仿。 因此可以將“mock”理解為一個替身，替代者. 在軟體開發中提及”mock”，通常理解為模擬物件或者Fake。

為什麼需要Mock?
Mock是為了解決units之間由於耦合而難於被測試的問題。所以mock object是unit test的一部分。

Mock的好處是什麼?
提前建立測試，TDD（測試驅動開發)這是個最大的好處吧。
如果你建立了一個Mock那麼你就可以在service介面建立之前寫Service Tests了，這樣你就能在開發過程中把測試新增到你的自動化測試環境中了。換句話說，模擬使你能夠使用測試驅動開發。

團隊可以並行工作
這類似於上面的那點；為不存在的程式碼建立測試。但前面講的是開發人員編寫測試程式，這裡說的是測試團隊來建立。當還沒有任何東西要測的時候測試團隊如何來建立測試呢？模擬並針對模擬測試！這意味著當service藉口需要測試時，實際上QA團隊已經有了一套完整的測試元件；沒有出現一個團隊等待另一個團隊完成的情況。這使得模擬的效益型尤為突出了。

你可以建立一個驗證或者演示程式
由於Mocks非常高效，Mocks可以用來建立一個概念證明，作為一個示意圖，或者作為一個你正考慮構建專案的演示程式。這為你決定專案接下來是否要進行提供了有力的基礎，但最重要的還是提供了實際的設計決策。

為無法訪問的資源編寫測試
這個好處不屬於實際效益的一種，而是作為一個必要時的“救生圈”。有沒有遇到這樣的情況？當你想要測試一個service介面，但service需要經過防火牆訪問，防火牆不能為你開啟或者你需要認證才能訪問。遇到這樣情況時，你可以在你能訪問的地方使用MockService替代，這就是一個“救生圈”功能。

Mock 可以交給使用者
在有些情況下，某種原因你需要允許一些外部來源訪問你的測試系統，像合作伙伴或者客戶。這些原因導致別人也可以訪問你的敏感資訊，而你或許只是想允許訪問部分測試環境。在這種情況下，如何向合作伙伴或者客戶提供一個測試系統來開發或者做測試呢？最簡單的就是提供一個mock，無論是來自於你的網路或者客戶的網路。

隔離系統
有時，你希望在沒有系統其他部分的影響下測試系統單獨的一部分。由於其他系統部分會給測試資料造成干擾，影響根據資料收集得到的測試結論。使用mock你可以移除掉除了需要測試部分的系統依賴的模擬。當隔離這些mocks後，mocks就變得非常簡單可靠，快速可預見。這為你提供了一個移除了隨機行為，有重複模式並且可以監控特殊系統的測試環境。

其實上面的特點總結成一句話：Mock可以解決測試物件的依賴問題，讓測試能夠只針對測試物件本身的邏輯，保證測試不受依賴的影響。

下面有個例子可以清晰的體現這一點，直接上程式碼：

public class OrderService {
    private PriceService priceService=new PriceService();

    private ProductService productService=new ProductService();

    /**
     * 該方法是返回訂單資訊
     * 依賴價格服務、商品服務
     * @param orderCode
     * @return
     */
    public OrderInfo getOrderInfoByOrderCode(String orderCode){
        PriceInfo priceInfo=priceService.getPriceInfoByProductCode("L3001");
        ProductInfo productInfo=productService.getProductInfoByProductCode("L3001");
        OrderInfo orderInfo=new OrderInfo();
        orderInfo.optionText=productInfo.optionText;
        orderInfo.productCode=productInfo.productCode;
        orderInfo.productName=productInfo.productName;
        orderInfo.price=priceInfo.price;
        return orderInfo;
    }
}

對於上面這個方法，在不使用Mockito來進行測試時，需要價格服務的getPriceInfoByProductCode和商品服務的getProductInfoByProductCode方法開發完成才能進行測試，下面是不使用Mockito的測試程式碼

public class OrderServiceTestWithJunit {
    private OrderService orderService;
    private ProductService productService;
    private PriceService priceService;
    @Before
    public void setUp() throws Exception {
        orderService=new OrderService();
        productService=new ProductService();
        priceService=new PriceService();
        ReflectionTestUtils.setField(orderService,"productService",productService);
        ReflectionTestUtils.setField(orderService,"priceService",priceService);
    }

    @Test
    public void getOrderInfoByOrderCode() throws Exception {
        OrderInfo orderInfo=orderService.getOrderInfoByOrderCode("testCode");
        Assert.assertNotNull(orderInfo);
    }

}

這樣的確可以完成對訂單服務的測試，但是前提是產品服務和價格服務已經完成且保證正確性，如果依賴的服務存在異常，這時異常將會從訂單服務丟擲，那麼定位異常將會非常麻煩。因此，對於這種有很多依賴的測試單元，只使用Junit或者TestNG,想要對測試單元本身的邏輯進行測試，幾乎是不可能的。

下面介紹用Mockito的做法

public class OrderServiceTestWithMock {
    @Mock
    private ProductService productService;
    @Mock
    private PriceService priceService;
    @InjectMocks
    private OrderService orderService;
    @BeforeClass
    public void setUp(){
        MockitoAnnotations.initMocks(this);
        setMockData();
    }

    private void setMockData() {
        when(priceService.getPriceInfoByProductCode(anyString())).thenAnswer(invoke->{
                PriceInfo priceInfo=new PriceInfo();
                priceInfo.price= BigDecimal.valueOf(100);
                return priceInfo;
        }
        );

        when(productService.getProductInfoByProductCode(anyString())).thenAnswer(invocation -> {
            ProductInfo productInfo=new ProductInfo();
            productInfo.optionText="10支裝";
            productInfo.productCode="L3001";
            productInfo.productName="mock商品";
            return productInfo;
        });
    }

    @Test
    public void testGetOrderInfoByOrderCode() throws Exception {
       OrderInfo orderInfo=orderService.getOrderInfoByOrderCode("Test");
       Assert.assertNotNull(orderInfo.optionText);
    }

}

2. 在專案中如何選擇測試框架？

JUnit 4 和 TestNG 在表面上是相似的，然而設計 JUnit 的目的是為了分析程式碼單元，而 TestNG 的預期用途則針對高階測試。對於大型測試套件，我們不希望在某一項測試失敗時就得重新執行數千項測試，TestNG 的靈活性在這裡尤為有用。這兩個框架都有自己的優勢，需要按照測試要求來選擇，不過對於開發來說其實選擇那一個沒有什麼太大的區別，因為用到的測試框架的功能不多，都是些基本的用法，對於微服務或者多人協作完成一個功能的情況下，Mockito是必須接入。

3.總結

其實開發寫測試用例是一個不斷梳理自己程式碼邏輯的過程，可能在寫的過程中你就發現了邏輯上的漏洞。