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 phổ biến.

Kiểm thử riêng biệt

ComposeTestRule cho phép bạn bắt đầu một hoạt động hiển thị bất kỳ thành phần kết hợp nào: toàn bộ ứng dụng, một màn hình hoặc một phần tử nhỏ. Bạn cũng nên kiểm tra để đảm bảo các thành phần kết hợp được đóng gói chính xác và hoạt động độc lập, cho phép kiểm thử giao diện người dùng một cách 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 và bạn 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 đó đã gọi quy tắc đó.

Mẫu phổ biến để thực hiện việc này là tạo AndroidComposeTestRule bằng cách sử dụng hoạt động trống, chẳng hạn 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 xác định một SemanticsPropertyKey mới và cung cấp mã đó 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 thành phần Compose được khôi phục chính xác khi tạo lại hoạt động hoặc quy trình. Thực hiện các bước kiểm tra như vậy 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 việc 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 phải 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 đều 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 hiển thị bằng thực thể Configuration hiện tại. Rất khó để kiểm thử nhiều cấu hình trực tiếp trong một chương trình kiểm thử vì 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 mục đích kiểm thử, cho phép bạn mô phỏng nhiều cấu hình thiết bị theo cách đã 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 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 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 quy trình kiểm thử không hỗ trợ trực tiếp 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
    }
}

Để áp dụng nhiều chế độ ghi đè cùng lúc, 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")
    }
}

Tài nguyên khác

  • Kiểm thử ứng dụng trên Android: Trang đích chính của việc kiểm thử trên Android cung cấp cái nhìn rộng 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 liên quan đến việc kiểm thử một ứng dụng Android.
  • Kiểm thử cục bộ: Bạn có thể chạy một số 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. Điều này nghĩa là các bài 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 bài 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 một số thiết bị được cung cấp cho người dùng, bạn nên kiểm thử cho 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.