Android測試支援庫1.0現已釋出！

文 / Google Mobile-Ninjas 團隊的 Michael Amygdalidis、Stephan Linzner 和 Nick Korostelev

我們非常高興地宣佈，Android 測試支援庫 (ATSL) 1.0 版現已釋出。

ATSL 1.0 版對現有測試 API 進行了重要更新，不僅新增了許多新功能、還提升了效能和穩定性，同時還修復了若干問題。它可提供齊全的 API，功能與現已棄用的 Android 平臺測試 API 相當。此版本還新增了許多我們在 Google I/O 2017 論壇上討論過的功能，如為 Multiprocess Espresso 和 Android Test Orchestrator 提供原生支援。

我們也非常高興地宣佈，從 1.0 版開始，我們將在 Google 的 Maven 程式碼庫中分發版本，讓您能夠更輕鬆地使用 ATSL 進行構建。如需瞭解有關如何使用此程式碼庫的更多資訊，請參閱 Google Maven 程式碼庫入門指南。請注意，今後我們不再將測試基礎設施更新與平臺更新捆綁在一起。如果您尚未將您的測試升級至 ATSL，這次正是升級的絕佳機會。

最後，我們想要宣佈對我們的 Android 測試文件進行的一項重大更新。我們已將舊測試文件從我們的 GitHub 網站遷移至 developers.android.com/testing。所有測試文件現在都顯示在同一個位置，讓您更容易瞭解如何在 Android 上編寫和執行測試。

下面我們進入本博文的高潮部分，這一部分概要地介紹了我們將在此版本中提供的新 API 和工具。

Espresso 增強功能

Espresso 3.0.0 帶來了出色的新功能，並提升了整體效能。其中的一些亮點包括：Multiprocess Espresso、Idling Registry 和新的 Idling Resources。下面，我們更詳細地介紹一下這些新功能：

Multiprocess Espresso

從 Android O 開始，此平臺將包含對在您的應用預設程式之外進行儀器測試的支援。（在 Android O 之前，您只能在應用預設程式中測試應用元件。）Multiprocess Espresso 實現了這一支援。它允許您無縫測試跨程式界限的應用介面互動，同時仍可保證 Espresso 同步。

好訊息是，Espresso 可執行上述所有工作；您不必針對多程式對介面設定進行任何更改。您可以繼續像為單程式應用編寫測試一樣為多程式編寫 Espresso 測試，Espresso 將自動處理程式間通訊 (IPC) 和程式間同步。

下圖展示了 Espresso 的多個例項如何相互通訊：

如需瞭解有關 Multiprocess Espresso 及其用法的更多資訊，請檢視我們的文件：

https://developer.android.google.cn/training/testing/espresso/multiprocess.html

Multiprocess 示例：

https://github.com/googlesamples/android-testing/tree/master/ui/espresso/MultiProcessSample

Idling Registry

有些應用使用 Gradle 中的構建風味或依賴注入框架（如 Dagger）來生成註冊空閒資源的測試構建配置。其他應用只是通過其操作元件公開空閒資源。所有這些方法都存在一個問題，即它們會增加開發工作流程的複雜性，其中有些方法甚至會破壞封裝。藉助最新版本的 Espresso，通過引入新的 IdlingRegistry API，讓您可以更輕鬆地在應用程式碼中註冊空閒資源。IdlingRegistry 是一個輕量型登錄檔，它不會引入完整的 Espresso 庫，因此，您可以更輕鬆地從您的應用程式碼註冊資源。將此 API 與 Multiprocess Espresso 結合使用時，您可以在應用程式碼中註冊來自任何程式的空閒資源。

Espresso 類的註冊現已棄用。
Idling Resources
編寫自定義空閒資源非常耗時，因此，Espresso 3.0.0 現在附帶了更多可以直接使用的空閒資源，以同步您的執行緒。新資源包括：IdlingThreadPoolExecutor 和 IdlingScheduledThreadPoolExecutor。我們還將提供更多資源！

要利用新的空閒資源，請將以下新的依賴項新增到 build.gradle 檔案：

此外，之前在 Espresso contrib 中棄用的 CountingIdlingResource 已在此版本中移除。因此，您需要更新您的測試以使用新的 CountingIdlingResource 軟體包，其位於 Espresso 空閒資源中。如需完整的遷移詳細資訊，請參閱我們的版本說明：

https://developer.android.google.cn/topic/libraries/testing-support-library/release-notes.html

ProviderTestRule

現在，測試 ContentProvider 物件時，您可以使用 ProviderTestRule 替代 ProviderTestCase2。ProviderTestRule 讓您可以更輕鬆地使用 AndroidJUnit4 當前可用的其他測試規則。

ProviderTestRule 包括用於初始化的 API，以及針對正在測試的 ContentProvider 執行的命令。如果您的 ContentProvider 基於 SQLite 資料庫，您可以使用用於設定資料庫檔案的 ProviderTestRule 命令和初始化命令。

如需瞭解更多資訊，請查閱 ProviderTestRule 文件：

https://developer.android.google.cn/reference/android/support/test/rule/provider/ProviderTestRule.html

授予許可權規則

Android M（API 級別 23）允許應用在執行時請求許可權。不過，請求執行時許可權的對話方塊將使測試進入無法繼續的狀態，從而導致測試失敗。通過使用 GrantPermissionRule，您可以跳過所有彈出對話方塊，並模擬使用者為您的應用授予執行時許可權。

Android Test Orchestrator

AndroidJUnitRunner 通常在同一個儀器程式中執行所有測試，這會導致許多問題。例如，這些測試會共享它們在記憶體中的狀態，如果一個測試崩潰，它將阻止測試套件的其餘測試執行。

儘管可以通過發起序列 adb 命令隔離測試，但此程式會增加主機端處理負載。通過改用全新的 Android Test Orchestrator，您可以在裝置上實現完全的測試隔離，如下圖所示：

請注意，如果您的測試 需要 傳遞共享狀態，則協調器會導致它們失敗。此行為是設計使然。截至本博文釋出時，Android Test Orchestrator 已進入 Beta 測試階段，可通過命令列使用。我們計劃不久推出 Firebase Test Lab 和 Android Studio 整合。

如需瞭解詳細資訊，請參閱 Android Testing Orchestrator 開發者指南：

https://developer.android.google.cn/training/testing/junit-runner.html#using-android-test-orchestrator

AndroidJUnitRunner

AndroidJUnitRunner 現在包含許多附加功能：

• 您可以使用 JUnitParams。

• 您可以使用執行器引數來配置類載入器和自定義 JUnit 測試過濾器。

有時，作為測試工作流程的一部分，您需要對您實時建立和配置的操作元件進行測試。現在，您可以使用一個 InterceptingActivityFactory 配置 MonitoringInstrumentation（並擴充套件到 AndroidJUnitRunner）。您可以使用一個特定於測試的配置建立要測試的操作元件，無需依賴編譯時注入。

上面的概述僅重點介紹了我們對 ATSL 進行的一些最重要變更。此外，還有更多值得探索的變更。如需完整的版本詳細資訊，請參閱我們的版本說明：

https://developer.android.com/topic/libraries/testing-support-library/release-notes.html

最後，我們想感謝為此版本貢獻功能的所有開發者。我們還要感謝來自 American Express、Slack 的移動工程團隊的 Android 測試專家以及 GDE Chiu-Ki Chan，感謝他們與我們大力合作和針對 Android 測試支援庫預發行版提供寶貴的反饋意見。

ATSL 團隊祝您測試愉快！

檢視全文及文中連結，請點選文末“閱讀原文”。

推薦閱讀：

拋棄硬體抽象層 (HAL)

什麼？Android O 圖示能自適應了？！

Google現已推出Android版Motion Stills

萬眾矚目Instant Apps終於全面問世啦