Android UI 自動化測試
概述
這篇博文回顧了關注于快速、可靠、便于調試的 Android UI 測試的4種策略。
在我們開始之前，請不要忘記一個首要原則（import rule）：可以用單元測試完成的工作應該使用單元測試完成。Robolectric 和 gradle unit tests support 是用于 Android 的非常好的單元測試框架范例。從另一個角度來說， UI 測試是用來檢查你的應用是否能對用戶在設備上一系列操作進行正確的 UI 反饋。 Expresso 是一個良好的、用于在同一進程中運行 UI 動作及校驗的框架。如果想了解關于 Espresso 和 UI 自動化工具，請查看 test support libraries 。
Google+ 團隊對 UI 測試進行了很多次嘗試。后面我們會討論在 UI 測試中采用各種策略后學到的東西。想知道更多的細節或者代碼示例，請保持關注。
策略1：使用端到端（End-To-End）測試的方法來做 UI 測試
我們先說明一些術語。 UI 測試用于檢查你的應用是否能對用戶在設備上一系列操作進行正確的 UI 反饋。 端到端（E2E）測試構建一個應用的完整的系統（包括后臺服務器及客戶端應用）。E2E 測試會檢查數據是否被正確傳送到客戶端應用以及整個系統功能的正確性。
通常為了讓應用 UI 功能能正常使用，你需要獲得從后臺服務器發出的數據，所以 UI 測試需要模擬這些數據（不一定通過后臺服務器）。在多數情況下， UI 測試的概念會和 E2E 測試混淆，因為端到端測試和手工場景測試很相似。然而，調試和保持 E2E 測試的穩定性非常困難，因為存在太多環境因素了，例如網絡碎片（network flakiness），真實服務器的認證服務，系統規模等。
- 龐大且緩慢的測試
- 由于超時和內存問題導致的高碎片率（flakiness rate，沒找到合適的譯名。大致意思就是用例不穩定，有時通過有時不通過，不通過的原因大多是環境造成的）
- 難以調試/探索為何失敗
- 認證問題（例如在自動化測試中進行認證會非常需要技巧）
讓我們看看怎么通過下面的策略來解決這些問題。
策略2：使用 Fake （偽造）服務器進行封閉的 UI 測試
在這個策略中，你避免了網絡通訊及額外的依賴，但你需要提供具有能驅動 UI 的數據的應用。更新你的應用來和本地服務器——而不是外部服務器——進行通訊，并建立一個 fake 本地服務器來提供數據到你的應用。你需要一種能生成被測應用需要的數據的機制。取決于你的系統架構，這可以通過多種方法完成。其中一種就是記錄服務器返回 消息并在你的 fake 服務器中重播（replay）。
一旦你有了一個封閉的、與本地 fake 服務器通訊的 UI 測試環境，你同時應該有一些封閉的系統測試。通過這種方式，你把 E2E 測試分割成服務端測試和客戶端測試，以及一個用于驗證服務端和客戶端同步的集成測試（更多關于集成測試的細節，請看博文的后端測試章節）
現在，客戶端測試流程如下圖：
雖然這種方法大幅度縮小了測試規模和碎片率（flakiness rate），你仍然需要像你的測試那樣維護一個額外的 fake 服務器。由于你用兩個不停變動的部分：測試用例及本地服務器，調試同樣并不簡單。雖然通過這種方法大幅度提高了測試穩定性，但本地服務器會造成一些碎片 （flakes）。
讓我們看看如何改善這點…
策略3：對應用設計進行依賴注入
為了去掉在 Android 上 fake 服務器這種額外的依賴，你應該對你的應用使用依賴注入來把一些真實模塊的實現替換成偽造的（fake）。其中一個例子是 Dagger ，如果有需要，你也可以設計你自己的依賴注入機制。
這會提高你的應用在單元測試及 UI 測試中的可測性（testability），讓你的測試能 mock （模擬）依賴。在 instrumentation 測試中， 測試的apk和被測應用都加載在在同一進程中，所以測試代碼能在運行時訪問應用代碼。不僅如此，你還可以使用 classpath 重載（實際上就是把測試的 classpath 優先級提高到比被測應用的高）來重載一個現有的類并注入測試代碼。舉個例子，為了讓你的測試變得封閉（hermetic），你的應用應該支持網絡實現的注 入。在測試過程中，測試會注入一個 fake 的網絡實現到應用中，而 fake 的實現會提供種子數據（seeded data）來替代后端服務器。
策略4：讓應用通過使用多個小型庫來進行構建（Building Apps into Smaller Libraries ，可以理解為模塊化）
如果你希望把你的應用擴展到擁有大量的模塊和視圖，并計劃在維護穩定版本的同時加入更多的特性并進行快速構建/測試，那你就需要把應用構建成多個小 的組件/庫。每個庫應該有自己的 UI 資源和用戶依賴管理（user dependency management）。這種策略不僅允許通過 mock 庫的依賴來進行封閉測試，還能像一個對于應用多個組件進行測試的測試平臺那樣提供服務。
一旦你擁有支持依賴注入的小型組件，你可以為每個組件單獨構建測試應用。
測試應用能帶來你的庫使用的實際 UI ，所需的 fake 數據，以及 moke 依賴。你能針對這些測試應用進行 Espresso 測試。這讓測試小型且相互隔離的庫成為可能。
舉個例子，讓我們看看構建用于應用的登陸和設置功能的小型庫：
設置組件的測試現在看起來是這樣的：
總結
對于 Android 富功能應用（rich apps）進行 UI 測試會非常具有挑戰性。以下是一些 Google+ 團隊在 UI 測試中學到的經驗總結：
1. 不要用 E2E 測試用來做 UI 測試。應該在 UI 測試之外編寫單元測試和系統測試來替代這種方式
2. 封閉測試才是正確的道路
3. 在設計應用時使用依賴注入
4. 把你的應用設計成使用小型庫/模塊組成（即模塊化），并在隔離的狀態下分別測試他們。然后你就可以有一些集成測試來驗證各模塊之間的集成是否正確。
5. 組件式 UI 測試已經被證明比 E2E 測試更快速且穩定性在99%以上。快速和穩定的測試已被證明能大幅度提高開發產出率。