本頁概述測試 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 架構，也請使用依附元件插入。
後續步驟
現在您已瞭解測試原因和兩種主要測試類型後，請參閱「要測試哪些項目」或瞭解「測試策略」一文
或者，如果您想建立第一個測試並透過實作學習，請參閱測試程式碼研究室。