摘要：解決這些問題并且練習這些調(diào)用的一個絕妙方法是，使用一個很好的一個測試雙庫通用程序。當服務器做出響應時，會使用響應數(shù)據(jù)執(zhí)行回調(diào)方法。目前為止，的威力真的很贊。

測試與API交互的HTTP調(diào)用是一件令人生厭的復雜事情。測試一個真實的Web服務器時，一大堆問題隨之產(chǎn)生：脆性測試（brittle test，因為網(wǎng)絡(luò)或API本身的問題而導致的測試失?。?、速度減慢測試（slow test，每一次HTTP調(diào)用都要花費好幾秒）和不完全測試（“如何觸發(fā)一個速率限制越界用例？想一想，我只希望速率限制會起作用……”）。

像Android這樣的平臺HTTP理應是異步調(diào)用，問題會變得更加復雜。如果在這些測試組合中添加計時器，那么你就準備好在測試API調(diào)用上認輸吧。

解決這些問題并且練習這些HTTP調(diào)用的一個絕妙方法是，使用一個很好的Mockito（一個Java測試雙庫 double library）通用程序：ArgumentCaptor。

ArgumentCaptor與混合測試雙有幾分相似；有點類似存根（stub），也有點類似偵聽程序（spy），但不完全是其中任何一個。可以使用參數(shù)捕獲器捕獲并存儲傳給mock/stub的參數(shù)。然而這里真正的亮點是對捕獲的參數(shù)進行方法調(diào)用，對于像Retrofit回調(diào)有很大幫助。

譯注：Retrofit是一個Android & Java的類型安全REST客戶端。

有了Retrofit，我們可以發(fā)起一個API調(diào)用并提供一個回調(diào)方法。當服務器做出響應時，Mockito會使用響應數(shù)據(jù)執(zhí)行回調(diào)方法。

下面這些代碼使用Github API查詢用戶代碼倉庫：

這里有三個我們想要測試的用例：理想路徑（happy path，獲取一些代碼倉庫并把傳遞給適配器）、錯誤路徑（error path，向用戶提示服務器錯誤）、特殊用例（special case, 向用戶提示沒有代碼倉庫錯誤）。

如果你的測試依賴于在真實的API服務器，那么第二和第三個用例會很復雜。我了解到最近GitHub有一些DDOS問題，但你肯定不能依賴它們來測試你的錯誤用例！

然而我們可以通過ArgumentCaptor捕獲回調(diào)參數(shù)，進而完全控制發(fā)送的數(shù)據(jù)。

看一下對理想路徑的測試（我用的是Robolectri，建議你也嘗試一下)：

captor(cb)捕獲到回調(diào)，調(diào)用getValue()方法以后，通過success方法向它傳遞一些偽對象（dummy object）。

你可能會感嘆“啊哈（原來可以這么簡單）”。呵呵，如果沒有也沒關(guān)系。接下來可以看一下對錯誤路徑的測試：

像之前一樣，我們捕獲了回調(diào)。但是這一次我們調(diào)用了failure方法，它模擬了一個API錯誤。如果我們需要更有針對性的錯誤處理（例如：如果返回狀態(tài)是401，就重定向再登陸；如果是500， 彈出一條普通的系統(tǒng)錯誤消息），可以通過創(chuàng)建合適RetrofitError對象作為failure調(diào)用的參數(shù)。

目前為止，ArgumentCaptor的威力真的很贊。我們完全控制了捕獲到的對象，并且能夠給這些對象設(shè)置任意的數(shù)據(jù)或者觸發(fā)任意想要測試的錯誤。

為了讓內(nèi)容更加豐富，下面是對一個特殊用例的測試：

（你可以在GitHub上找到示例的全部源碼和工程文件）。

有一個特殊細節(jié)要注意：如果在聲明捕獲器時使用了Mockito注解，

請確保在設(shè)置中的某個地方添加了下面代碼：

這種測試方法完全符合書中提到的所有特點：快速、健壯、易于使用。我們還可以通過它很容易地測試項目中很少出現(xiàn)的邊緣情況（會話超時、服務器維護、特殊值)，確保我們的應用正常運行。

雖然本文示例是專門針對某種棧（Android、Robolectric、Retrofit、Mockito），但是類似的方法幾乎適用于任何應用。

祝測試愉快！

原文 Reliable API testing for Android with Retrofit and Mockito
翻譯 Peter Pan
via www.importnew