รูปแบบทั่วไป

คุณสามารถทดสอบแอป Compose โดยใช้แนวทางและรูปแบบที่ผ่านการพิสูจน์แล้ว

ทดสอบแบบแยกเดี่ยว

ComposeTestRule ช่วยให้คุณเริ่มกิจกรรมที่แสดงคอมโพสิเบิลได้ ไม่ว่าจะเป็นแอปพลิเคชันทั้งแอป หน้าจอเดียว หรือองค์ประกอบเล็กๆ นอกจากนี้ คุณควรตรวจสอบด้วยว่าคอมโพสิเบิลได้รับการบรรจุอย่างถูกต้องและทำงานได้อย่างอิสระ เพื่อให้การทดสอบ UI ง่ายขึ้นและมุ่งเน้นมากขึ้น

แต่ไม่ได้หมายความว่าคุณควรสร้างการทดสอบ UI ของหน่วยเท่านั้น การกําหนดขอบเขตการทดสอบ UI ส่วนสําคัญของ UI ก็มีความสำคัญมากเช่นกัน

เข้าถึงกิจกรรมและแหล่งข้อมูลหลังจากตั้งค่าเนื้อหาของคุณเอง

บ่อยครั้งที่คุณต้องตั้งค่าเนื้อหาที่ทดสอบโดยใช้ composeTestRule.setContent และคุณยังต้องเข้าถึงทรัพยากรกิจกรรมด้วย เช่น เพื่อยืนยันว่าข้อความที่แสดงตรงกับทรัพยากรสตริง อย่างไรก็ตาม คุณจะเรียก setContent ในกฎที่สร้างด้วย createAndroidComposeRule() ไม่ได้หากกิจกรรมเรียก setContent อยู่แล้ว

รูปแบบทั่วไปในการดำเนินการนี้คือการสร้าง AndroidComposeTestRule โดยใช้กิจกรรมว่าง เช่น 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()
    }
}

โปรดทราบว่าต้องเพิ่ม ComponentActivity ลงในไฟล์ AndroidManifest.xml ของแอป เปิดใช้โดยเพิ่ม Dependency นี้ลงในข้อบังคับ

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

พร็อพเพอร์ตี้ความหมายที่กําหนดเอง

คุณสามารถสร้างพร็อพเพอร์ตี้ Semantics ที่กําหนดเองเพื่อแสดงข้อมูลในการทดสอบ โดยให้กําหนด 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()

ยืนยันการคืนค่าสถานะ

ตรวจสอบว่าสถานะขององค์ประกอบการเขียนได้รับการกู้คืนอย่างถูกต้องเมื่อสร้างกิจกรรมหรือกระบวนการอีกครั้ง ดำเนินการตรวจสอบดังกล่าวโดยไม่ต้องอาศัยการสร้างกิจกรรมใหม่ด้วยคลาส 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: หน้า Landing Page หลักของการทดสอบ Android ให้มุมมองที่กว้างขึ้นเกี่ยวกับพื้นฐานและเทคนิคการทดสอบ
  • หลักพื้นฐานของการทดสอบ: ดูข้อมูลเพิ่มเติมเกี่ยวกับแนวคิดหลักเบื้องหลังการทดสอบแอป Android
  • การทดสอบในเครื่อง: คุณสามารถทำการทดสอบบางอย่างในเครื่องของคุณเอง
  • การทดสอบที่มีเครื่องมือวัด: คุณควรทำการทดสอบที่มีเครื่องมือวัดด้วย กล่าวคือ การทดสอบที่ทํางานในอุปกรณ์โดยตรง
  • การรวมอย่างต่อเนื่อง: การรวมอย่างต่อเนื่องช่วยให้คุณผสานรวมการทดสอบเข้ากับไปป์ไลน์การนำส่งได้
  • ทดสอบขนาดหน้าจอต่างๆ: เนื่องจากผู้ใช้มีอุปกรณ์หลายรุ่น คุณจึงควรทดสอบขนาดหน้าจอต่างๆ
  • Espresso: แม้ว่าจะมีไว้สำหรับ UI ที่อิงตามมุมมอง แต่ความรู้เกี่ยวกับ Espresso ยังคงมีประโยชน์สำหรับบางแง่มุมของการทดสอบ Compose