本頁面概述測試 Android 應用程式的核心原則，包括主要最佳做法及其優點。
測試的好處
測試是應用程式開發流程中不可或缺的一環。藉由持續測試應用程式，您可以在公開發布應用程式前，驗證應用程式的正確性、功能行為和可用性。
您可以手動測試應用程式，您可能會使用不同的裝置和模擬器、變更系統語言，並嘗試產生每個使用者錯誤，或是周遊每個使用者流程。
不過，手動測試的規模會偏低，而且可能很容易忽略應用程式行為中的迴歸問題。自動化測試牽涉到使用工具為您執行測試，速度更快、更可重複，通常也會在開發程序的早期階段提供您更多與應用程式相關的實用意見回饋。
Android 中的測試類型
行動應用程式相當複雜，必須在許多環境中正常運作。因此，測試的類型也很多。
主旨
例如，視主旨而定，會有不同的測試類型：
- 功能測試：我的應用程式是否能正常運作？
- 效能測試：是否能快速且有效率地完成？
- 無障礙測試：應用程式是否能順利使用無障礙服務？
- 相容性測試：在所有裝置和 API 級別上都適用嗎？
範圍
測試方式也會因大小或隔離程度而有所不同：
- 單元測試或小型測試只能驗證應用程式中極小的部分，例如方法或類別。
- 「端對端」測試或「大型測試」可同時驗證應用程式的較大部分，例如整個螢幕或使用者流程。
- 中等測試則介於兩者之間，可檢查兩個或更多單位之間的整合。
分類測試的方法有很多種，不過，對應用程式開發人員來說，最重要的差異在於測試執行位置。
檢測設備測試與本機測試
您可以在 Android 裝置或其他電腦上執行測試：
- 檢測設備測試會在 Android 裝置 (實體或模擬) 上執行。應用程式會與測試應用程式一併建構及安裝，以便插入指令並讀取狀態。檢測設備測試通常是 UI 測試，用來啟動應用程式，然後與應用程式互動。
- 本機測試會在開發機器或伺服器上執行，因此也稱為「主體端測試」。這些測試通常體積小且速度快，可將測試主題與應用程式的其他部分隔離。
並非所有單元測試都是本機測試，也並非所有裝置都會執行端對端測試。例如：
- 大型本機測試：您可以使用在本機執行的 Android 模擬器，例如 Robolectric。
- 小規模檢測設備測試：您可以使用架構功能 (例如 SQLite 資料庫) 驗證程式碼是否能正常運作。您可以在這項測試中使用多部裝置，檢查與多個 SQLite 版本的整合情形。
範例
以下程式碼片段示範如何在檢測設備 UI 測試中與 UI 互動，點按元素並驗證是否會顯示另一個元素。
Espresso
// When the Continue button is clicked
onView(withText("Continue"))
.perform(click())
// Then the Welcome screen is displayed
onView(withText("Welcome"))
.check(matches(isDisplayed()))
Compose UI
// When the Continue button is clicked
composeTestRule.onNodeWithText("Continue").performClick()
// Then the Welcome screen is displayed
composeTestRule.onNodeWithText("Welcome").assertIsDisplayed()
下列程式碼片段為 ViewModel (本機主機端測試) 單元測試的一部分：
// Given an instance of MyViewModel
val viewModel = MyViewModel(myFakeDataRepository)
// When data is loaded
viewModel.loadData()
// Then it should be exposing data
assertTrue(viewModel.data != null)
可測試的架構
若是可測試的應用程式架構，此程式碼會遵循一個結構，方便您單獨測試程式碼的不同部分。可測試的架構還有其他優點，例如可讀性、可維護性、可擴充性和可重用性。
「無法測試」的架構會產生以下內容：
- 測試規模越大、速度越慢，不穩定的測試就越多。無法進行單元測試的類別可能必須涵蓋規模較大的整合測試或 UI 測試。
- 測試不同情境的機會較少。大型測試的速度較慢，因此測試應用程式的所有可能狀態可能並不切實際。
如要進一步瞭解架構指南，請參閱應用程式架構指南。
解耦方法
如果您可以從其他部分中擷取部分函式、類別或模組，測試起來會更輕鬆、更有效率。這種做法稱為分離，對可測試架構而言是最重要的概念。
常見的解耦技術包括：
- 將應用程式分割成不同層級，例如呈現層、網域層和資料層。您也可以將應用程式分割為「模組」，每個模組一個。
- 避免在具有大量依附元件的實體 (例如活動和片段) 中加入邏輯。使用這些類別做為架構的進入點，並將UI 和商業邏輯移至其他位置，例如可組合項、ViewModel 或網域層。
- 避免在包含商業邏輯的類別中使用直接的架構相依性。舉例來說，請勿在 ViewModel 中使用 Android 情境。
- 簡化依附元件的取代。例如，請使用介面，而非具體實作。即使您未使用 DI 架構，也請使用依附元件插入。
後續步驟
您現在已瞭解為何要進行測試，以及兩種主要的測試類型，可以參閱「要測試什麼」或瞭解「測試策略」。
或者，如果您想建立第一個測試並透過實作學習，請參閱測試程式碼研究室。