我們非常高興地宣布，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 及其用法的更多信息，請查看我們的 文檔 和? Multiprocess 示例 。
Idling Registry
有些應用使用 Gradle 中的構建風味或依賴注入框架（如 Dagger）來生成注冊空閑資源的測試構建配置。其他應用只是通過其操作組件公開空閑資源。所有這些方法都存在一個問題，即它們會增加開發工作流程的復雜性，其中有些方法甚至會破壞封裝。借助最新版本的 Espresso，通過引入新的? IdlingRegistry ?API，讓您可以更輕松地在應用代碼中注冊空閑資源。 IdlingRegistry ?是一個輕量型注冊表，它不會引入完整的 Espresso 庫，因此，您可以更輕松地從您的應用代碼注冊資源。將此 API 與 Multiprocess Espresso 結合使用時，您可以在應用代碼中注冊來自任何進程的空閑資源。

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

要利用新的空閑資源，請將以下新的依賴項添加到 build.gradle 文件：
androidTestCompile "com.android.support.test.espresso.idling:idling-concurrent:3.0.0"
此外，之前在 Espresso contrib 中棄用的? CountingIdlingResource ?已在此版本中移除。因此，您需要更新您的測試以使用新的? CountingIdlingResource ?軟件包，其位于 Espresso 空閑資源中。如需完整的遷移詳細信息，請參閱我們的 版本說明 。

ProviderTestRule

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

ProviderTestRule ?包括用于初始化的 API，以及針對正在測試的? ContentProvider ?運行的命令。如果您的? ContentProvider ?基于 SQLite 數據庫，您可以使用用于設置數據庫文件的? ProviderTestRule ?命令和初始化命令。

如需了解更多信息，請查閱? ProviderTestRule ?文檔。

授予權限規則

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 開發者指南 。

AndroidJUnitRunner

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

• 您可以使用?JUnitParams。
• 您可以使用運行器參數來配置類加載器和自定義 JUnit 測試過濾器。

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

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

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

ATSL 團隊祝您測試愉快！

原文鏈接

http://developers.googleblog.cn/2017/08/android-10.html

總結

以上是生活随笔為你收集整理的Android 测试支持库 1.0 现已发布！的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。