Android 寫測試用例的注意事項

<b>本文講的是Android 寫測試用例的注意事項，</b>

<b></b>

在本文中，我将根據我的經驗來嘗試解釋寫測試用例的最佳實踐。我會在本文中使用 Espresso 代碼，但是這些實踐都可以應用在單元測試和 UI 測試上。為了更好的解釋，我以一個新聞應用作為例子。

下面提到的應用的功能和條件純屬虛構，僅僅是為了解釋這個最佳實踐，并且與 Play 商店中上架或者已下架的任何應用不相似。:P

該新聞應用有以下界面

語言選擇 — 當使用者第一次打開應用時，他必須選擇至少一種語言。選擇一種或多種語言後，使用者的選擇将會儲存到 shared preferences 中，然後使用者将會直接跳轉到新聞清單界面。

新聞清單 — 當使用者打開新聞清單界面，請求和語言參數将會發送到伺服器，然後響應結果将會顯示到 recycler view （id 為 news_list ）上。如果 shared preference 沒有該語言或者伺服器沒有給出成功的響應，錯誤界面将會對使用者可見并且 recycler view 将會消失。新聞清單界面有一個按鈕，如果使用者隻選擇了一種語言，按鈕顯示為 “Change your Language”，如果使用者選擇了多種語言，則顯示為 “Change your Languages”。（我向上帝發誓，這是一個虛構的應用）

新聞詳情 — 顧名思義，當使用者點選任何新聞清單條目的時候，該應用将被啟動。

應用的功能都已經足夠了。讓我們來看看為新聞清單界面寫的測試用例。這是我最開始寫的代碼。

在第一個測試用例 testClickOnAnyNewsItem() 中，如果伺服器沒有發送成功的響應，這個測試用例将會失敗，因為 recycler view 的 visibility 是 GONE。但這并不是測試用例的目的。這個測試用例要通過或者失敗，最低的要求是 recycler view 要顯示，如果因為某些原因沒有顯示，那麼這個測試用例不應該視為失敗。該測試的正确代碼應該像這樣。

當我開始測試時，我總是按照以下順序測試界面

語言選擇

新聞清單

新聞詳情

因為我首先測試了語言選擇界面，是以在測試新聞清單界面之前，一種語言已經被設定好了。但是當我先測試新聞清單界面時，該測試就失敗了。失敗的原因很簡單 — 語言沒有選擇，是以 recycler view 也就不顯示。是以，測試用例的執行順序不應該影響到測試結果。是以，在運作測試用例之前，語言選項應該被儲存到 shared preferences 中，這樣的話，該測試用例就獨立于語言選擇界面的測試了。

在第二個測試用例 testChangeLanguageFeature() 中，我們獲得使用者選擇的語言種類數，然後基于此，我們寫了一個 if-else 的條件來測試。但是 if-else 條件應該寫在你的實際代碼中，而不是寫在測試代碼裡。每一個條件都應該單獨測試。是以，我們應該寫如下的兩個測試用例，而不是一個。

在大多數應用中，我們都要與外部代理如網絡和資料庫進行互動。測試用例可以在執行過程中調用一個請求發送到伺服器，響應可能成功或者失敗。但是如果伺服器的響應失敗了，那麼這個測試用例不應該視為失敗。我們這樣考慮 — 如果測試用例失敗了，然後我們在我們的用戶端代碼中進行更改，以便測試代碼可以正常工作。但是在這種情況下，我們是否需要對用戶端代碼進行任何更改？— 不。

但是你也不應該完全避免測試網絡請求和響應。由于伺服器是外部代理，是以可能存在一種情況，當它發送一些錯誤響應時，這可能會導緻應用崩潰。是以，你寫的測試用例應該覆寫伺服器所有可能的響應，甚至是那種伺服器永遠不會發送的響應。以此方法，所有的代碼都将被覆寫，然後確定應用能優雅的處理所有的響應并且不崩潰。

以正确的方式編寫測試用例與編寫用于測試的代碼一樣重要。

<b>原文釋出時間為：2017年1月14日</b>

<b>本文來自雲栖社群合作夥伴掘金，了解相關資訊可以關注掘金網站。</b>