常見模式

您可以使用完善的方法和模式來測試 Compose 應用程式。

獨立測試

ComposeTestRule 可讓您啟動顯示任何可組合項的活動：完整應用程式、單一畫面或小型元素。此外，我們也建議您檢查可組合項是否正確封裝及獨立運作，藉此簡化並更聚焦的 UI 測試。

這不代表只能建立單元 UI 測試。對 UI 中範圍較大的部分進行的測試也同樣重要。

設定自己的內容後存取活動和資源

您通常需要使用 composeTestRule.setContent 設定要測試的內容，也需要存取活動資源，例如宣告顯示的文字與字串資源相符。不過，如果活動已呼叫 setContent，您就無法在使用 createAndroidComposeRule() 建立的規則中呼叫 setContent。

為此，常見的模式是使用 ComponentActivity 等空白活動建立 AndroidComposeTestRule。

class MyComposeTest {

    @get:Rule
    val composeTestRule = createAndroidComposeRule<ComponentActivity>()

    @Test
    fun myTest() {
        // Start the app
        composeTestRule.setContent {
            MyAppTheme {
                MainScreen(uiState = exampleUiState, /*...*/)
            }
        }
        val continueLabel = composeTestRule.activity.getString(R.string.next)
        composeTestRule.onNodeWithText(continueLabel).performClick()
    }
}

請注意，您必須在應用程式的 AndroidManifest.xml 檔案中新增 ComponentActivity。將此依附元件新增至模組即可啟用這項功能：

debugImplementation("androidx.compose.ui:ui-test-manifest:$compose_version")

自訂語意屬性

您可以建立自訂語意屬性，向測試對象公開資訊。方法是定義新的 SemanticsPropertyKey，並透過 SemanticsPropertyReceiver 提供。

// Creates a semantics property of type Long.
val PickedDateKey = SemanticsPropertyKey<Long>("PickedDate")
var SemanticsPropertyReceiver.pickedDate by PickedDateKey

現在，請在 semantics 修飾符中使用該屬性：

val datePickerValue by remember { mutableStateOf(0L) }
MyCustomDatePicker(
    modifier = Modifier.semantics { pickedDate = datePickerValue }
)

在測試中，請使用 SemanticsMatcher.expectValue 聲明屬性的值：

composeTestRule
    .onNode(SemanticsMatcher.expectValue(PickedDateKey, 1445378400)) // 2015-10-21
    .assertExists()

驗證狀態還原

確認重新建立活動或程序後，Compose 元素的狀態已正確還原。可使用 StateRestorationTester 類別執行這類檢查，無須依賴活動重建。

這個類別可讓您模擬可組合項的重新建立。特別適合用來驗證 rememberSaveable 的實作。


class MyStateRestorationTests {

    @get:Rule
    val composeTestRule = createComposeRule()

    @Test
    fun onRecreation_stateIsRestored() {
        val restorationTester = StateRestorationTester(composeTestRule)

        restorationTester.setContent { MainScreen() }

        // TODO: Run actions that modify the state

        // Trigger a recreation
        restorationTester.emulateSavedInstanceStateRestore()

        // TODO: Verify that state has been correctly restored.
    }
}

測試不同的裝置設定

Android 應用程式必須適應許多不斷變化的條件，例如視窗大小、語言代碼、字型大小、深色和淺色主題等等。這些條件大多衍生自使用者控制的裝置層級值，並以目前的 Configuration 執行個體公開。由於測試必須設定裝置層級屬性，因此直接在測試中測試不同設定並不容易。

DeviceConfigurationOverride 是僅供測試的 API，可讓您針對測試中的 @Composable 內容，以本地化方式模擬不同的裝置設定。

DeviceConfigurationOverride 的隨附物件包含下列擴充功能函式，可覆寫裝置層級設定屬性：

如要套用特定覆寫值，請將待測試的內容納入 DeviceConfigurationOverride() 頂層函式的呼叫中，然後將要套用的覆寫值做為參數傳遞。

舉例來說，以下程式碼會套用 DeviceConfigurationOverride.ForcedSize() 覆寫以在本機變更密度，強制 MyScreen 可組合項在大型橫向視窗中轉譯，即使執行測試的裝置不支援直接使用該視窗大小也一樣：

composeTestRule.setContent {
    DeviceConfigurationOverride(
        DeviceConfigurationOverride.ForcedSize(DpSize(1280.dp, 800.dp))
    ) {
        MyScreen() // will be rendered in the space for 1280dp by 800dp without clipping
    }
}
DeviceConfigurationOverrideSnippets.kt

如要一次套用多個覆寫值，請使用 DeviceConfigurationOverride.then()：

composeTestRule.setContent {
    DeviceConfigurationOverride(
        DeviceConfigurationOverride.FontScale(1.5f) then
            DeviceConfigurationOverride.FontWeightAdjustment(200)
    ) {
        Text(text = "text with increased scale and weight")
    }
}
DeviceConfigurationOverrideSnippets.kt

其他資源

  • 在 Android 上測試應用程式：主要 Android 測試到達網頁提供了更全面的測試基礎知識和技巧。
  • 測試基礎知識：進一步瞭解測試 Android 應用程式的核心概念。
  • 本機測試：您可以在自己的工作站本機執行部分測試。
  • 檢測設備測試：建議您也執行檢測設備測試。也就是說，直接在裝置上執行的測試。
  • 持續整合：持續整合可讓您將測試整合至部署管道。
  • 測試不同的螢幕大小：有許多裝置可供使用者使用，建議您針對不同螢幕大小進行測試。
  • Espresso：雖然適用於以 View 為基礎的 UI，但 Espresso 知識在 Compose 測試的某些方面仍非常實用。