Mẫu kiểm thử phổ biến

Bạn có thể kiểm thử ứng dụng Compose bằng các phương pháp và mẫu đã được thiết lập.

Kiểm thử riêng biệt

ComposeTestRule cho phép bạn bắt đầu một hoạt động cho thấy thành phần kết hợp bất kỳ: toàn bộ ứng dụng, một màn hình đơn lẻ hoặc một phần tử nhỏ. Bạn cũng nên kiểm tra xem các thành phần kết hợp có được đóng gói chính xác và hoạt động độc lập hay không, cho phép kiểm thử giao diện người dùng dễ dàng và tập trung hơn.

Điều này không có nghĩa là bạn chỉ nên tạo các quy trình kiểm thử đơn vị khi kiểm thử giao diện người dùng. Việc kiểm thử trong phạm vi các phần lớn hơn trên giao diện người dùng cũng rất quan trọng.

Truy cập vào hoạt động và tài nguyên sau khi thiết lập nội dung của riêng bạn

Thông thường, bạn cần đặt nội dung đang được kiểm thử bằng cách sử dụng composeTestRule.setContent, đồng thời cũng cần truy cập vào tài nguyên hoạt động, chẳng hạn như để xác nhận rằng văn bản hiển thị khớp với tài nguyên chuỗi. Tuy nhiên, bạn không thể gọi setContent trên quy tắc được tạo bằng createAndroidComposeRule() nếu hoạt động này đã gọi quy tắc đó.

Một mẫu phổ biến để thực hiện việc này là tạo AndroidComposeTestRule bằng một hoạt động trống như ComponentActivity.

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()
    }
}

Xin lưu ý rằng bạn cần thêm ComponentActivity vào tệp AndroidManifest.xml của ứng dụng. Hãy bật tính năng đó bằng cách thêm phần phụ thuộc này vào mô-đun của bạn:

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

Thuộc tính ngữ nghĩa tùy chỉnh

Bạn có thể tạo các thuộc tính ngữ nghĩa tuỳ chỉnh để hiển thị thông tin cho quy trình kiểm thử. Để thực hiện việc này, hãy khai báo một SemanticsPropertyKey mới và cung cấp thuộc tính đó bằng cách sử dụng SemanticsPropertyReceiver.

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

Bây giờ, hãy sử dụng thuộc tính đó trong đối tượng sửa đổi semantics:

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

Từ các quy trình kiểm thử, hãy sử dụng SemanticsMatcher.expectValue để xác nhận giá trị của thuộc tính:

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

Xác minh quá trình khôi phục trạng thái

Xác minh rằng trạng thái của các phần tử Compose được khôi phục chính xác khi hoạt động hoặc quy trình được tạo lại. Thực hiện các bước kiểm tra đó mà không cần dựa vào việc tạo lại hoạt động bằng lớp StateRestorationTester.

Với lớp này, bạn có thể mô phỏng quá trình tạo lại một thành phần kết hợp. Việc xác minh quá trình triển khai rememberSaveable sẽ đặc biệt hữu ích.


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.
    }
}

Kiểm thử nhiều cấu hình thiết bị

Ứng dụng Android cần thích ứng với nhiều điều kiện thay đổi: kích thước cửa sổ, ngôn ngữ, kích thước phông chữ, giao diện tối và sáng, v.v. Hầu hết các điều kiện này bắt nguồn từ các giá trị cấp thiết bị do người dùng kiểm soát và được cung cấp qua thực thể Configuration hiện tại. Việc kiểm thử các cấu hình khác nhau ngay trong một kiểm thử là rất khó vì bài kiểm thử phải định cấu hình các thuộc tính cấp thiết bị.

DeviceConfigurationOverride là một API chỉ dành cho kiểm thử, cho phép bạn mô phỏng nhiều cấu hình thiết bị theo cách được bản địa hoá cho nội dung @Composable đang được kiểm thử.

Đối tượng đồng hành của DeviceConfigurationOverride có các hàm mở rộng sau đây. Các hàm này sẽ ghi đè các thuộc tính cấu hình ở cấp thiết bị:

Để áp dụng một chế độ ghi đè cụ thể, hãy gói nội dung đang được kiểm thử trong lệnh gọi đến hàm cấp cao nhất DeviceConfigurationOverride(), truyền chế độ ghi đè để áp dụng dưới dạng tham số.

Ví dụ: mã sau đây áp dụng cơ chế ghi đè DeviceConfigurationOverride.ForcedSize() để thay đổi mật độ cục bộ, buộc thành phần kết hợp MyScreen hiển thị trong một cửa sổ ngang lớn, ngay cả khi thiết bị đang chạy kiểm thử không trực tiếp hỗ trợ kích thước cửa sổ đó:

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

Để áp dụng nhiều chế độ ghi đè cùng nhau, hãy sử dụng DeviceConfigurationOverride.then():

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

Tài nguyên khác

  • Kiểm thử ứng dụng trên Android: Trang đích chính về kiểm thử Android cung cấp thông tin tổng quan hơn về các nguyên tắc và kỹ thuật kiểm thử.
  • Nguyên tắc cơ bản về kiểm thử: Tìm hiểu thêm về các khái niệm chính của việc kiểm thử ứng dụng Android.
  • Kiểm thử cục bộ: Bạn có thể chạy một số bài kiểm thử cục bộ trên máy trạm của riêng mình.
  • Kiểm thử đo lường: Bạn cũng nên chạy kiểm thử đo lường. Tức là các chương trình kiểm thử chạy trực tiếp trên thiết bị.
  • Tích hợp liên tục: Tính năng tích hợp liên tục cho phép bạn tích hợp các hoạt động kiểm thử vào quy trình triển khai.
  • Kiểm thử nhiều kích thước màn hình: Với nhiều thiết bị được cung cấp cho người dùng, bạn nên kiểm thử nhiều kích thước màn hình.
  • Espresso: Mặc dù dành cho giao diện người dùng dựa trên Khung hiển thị, nhưng kiến thức về Espresso vẫn có thể hữu ích cho một số khía cạnh của kiểm thử Compose.