การทดสอบ Compose จะซิงค์กับ UI โดยค่าเริ่มต้น เมื่อเรียกใช้การยืนยันหรือการดำเนินการด้วย ComposeTestRule
ระบบจะซิงค์การทดสอบล่วงหน้าโดยรอจนกว่าทรี UI จะไม่ได้ใช้งาน
โดยปกติแล้ว คุณไม่ต้องดำเนินการใดๆ อย่างไรก็ตาม คุณควรทราบถึงกรณีที่อาจเกิดขึ้น
เมื่อซิงค์การทดสอบแล้ว แอป Compose จะเลื่อนเวลาไปข้างหน้าโดยใช้ นาฬิกาเสมือน ซึ่งหมายความว่าการทดสอบ Compose จะไม่ทำงานแบบเรียลไทม์ จึงสามารถผ่านได้ โดยเร็วที่สุด
อย่างไรก็ตาม หากคุณไม่ได้ใช้วิธีการที่ซิงค์การทดสอบ จะไม่มีการ ประกอบใหม่เกิดขึ้นและ UI จะดูเหมือนหยุดชั่วคราว
@Test
fun counterTest() {
val myCounter = mutableStateOf(0) // State that can cause recompositions.
var lastSeenValue = 0 // Used to track recompositions.
composeTestRule.setContent {
Text(myCounter.value.toString())
lastSeenValue = myCounter.value
}
myCounter.value = 1 // The state changes, but there is no recomposition.
// Fails because nothing triggered a recomposition.
assertTrue(lastSeenValue == 1)
// Passes because the assertion triggers recomposition.
composeTestRule.onNodeWithText("1").assertExists()
}
โปรดทราบว่าข้อกำหนดนี้มีผลกับลำดับชั้นของ Compose เท่านั้น และไม่มีผลกับส่วนอื่นๆ ของแอป
ปิดใช้การซิงค์อัตโนมัติ
เมื่อเรียกการยืนยันหรือการดำเนินการผ่าน ComposeTestRule
เช่น
assertExists()
การทดสอบจะซิงค์กับ Compose UI ในบางกรณี
คุณอาจต้องการหยุดการซิงค์นี้และควบคุมนาฬิกาด้วยตนเอง เช่น คุณสามารถควบคุมเวลาเพื่อถ่ายภาพหน้าจอที่ถูกต้องของภาพเคลื่อนไหว ณ จุดที่ UI ยังคงทำงานอยู่ หากต้องการปิดใช้การซิงค์อัตโนมัติ ให้ตั้งค่าพร็อพเพอร์ตี้ autoAdvance
ใน mainClock
เป็น false
ดังนี้
composeTestRule.mainClock.autoAdvance = false
โดยปกติแล้ว คุณจะต้องเลื่อนเวลาด้วยตนเอง คุณสามารถเลื่อนไปทีละเฟรมได้ด้วยadvanceTimeByFrame()
หรือเลื่อนตามระยะเวลาที่ต้องการได้ด้วยadvanceTimeBy()
composeTestRule.mainClock.advanceTimeByFrame()
composeTestRule.mainClock.advanceTimeBy(milliseconds)
ทรัพยากรที่ไม่ได้ใช้งาน
Compose สามารถซิงค์การทดสอบและ UI เพื่อให้ทุกการดำเนินการและการยืนยัน เกิดขึ้นในสถานะว่าง โดยรอหรือเลื่อนเวลาตามต้องการ อย่างไรก็ตาม การดำเนินการแบบไม่พร้อมกันบางอย่างซึ่งผลลัพธ์มีผลต่อสถานะ UI สามารถเรียกใช้ใน เบื้องหลังได้โดยที่การทดสอบไม่ทราบถึงการดำเนินการเหล่านั้น
สร้างและลงทะเบียนทรัพยากรที่ไม่ได้ใช้งานเหล่านี้ในการทดสอบเพื่อให้ระบบนำไปพิจารณาเมื่อตัดสินว่าแอปที่อยู่ระหว่างการทดสอบกำลังทำงานหรือไม่ได้ใช้งาน คุณไม่จำเป็นต้องดำเนินการใดๆ เว้นแต่คุณจะต้องลงทะเบียนทรัพยากรที่ไม่ได้ใช้งานเพิ่มเติม เช่น หากคุณเรียกใช้ งานในเบื้องหลังที่ไม่ได้ซิงค์กับ Espresso หรือ Compose
API นี้คล้ายกับ Idling Resources ของ Espresso มาก เพื่อระบุว่า
ออบเจ็กต์ภายใต้การทดสอบไม่ได้ใช้งานหรือกำลังทำงานอยู่ ใช้กฎการทดสอบการเขียนเพื่อลงทะเบียน
การติดตั้งใช้งาน IdlingResource
composeTestRule.registerIdlingResource(idlingResource)
composeTestRule.unregisterIdlingResource(idlingResource)
การซิงค์ด้วยตนเอง
ในบางกรณี คุณต้องซิงค์ UI ของ Compose กับส่วนอื่นๆ ของ การทดสอบหรือแอปที่คุณกำลังทดสอบ
ฟังก์ชัน waitForIdle()
จะรอให้ Compose อยู่ในสถานะว่าง แต่ฟังก์ชัน
จะขึ้นอยู่กับพร็อพเพอร์ตี้ autoAdvance
composeTestRule.mainClock.autoAdvance = true // Default
composeTestRule.waitForIdle() // Advances the clock until Compose is idle.
composeTestRule.mainClock.autoAdvance = false
composeTestRule.waitForIdle() // Only waits for idling resources to become idle.
โปรดทราบว่าในทั้ง 2 กรณี waitForIdle()
จะรอการวาดและการจัดเลย์เอาต์
ที่รอดำเนินการด้วย
นอกจากนี้ คุณยังเลื่อนเวลาไปจนกว่าจะมีเงื่อนไขตรงตามที่กำหนดได้ด้วย advanceTimeUntil()
composeTestRule.mainClock.advanceTimeUntil(timeoutMs) { condition }
โปรดทราบว่าเงื่อนไขที่ระบุควรตรวจสอบสถานะที่อาจได้รับผลกระทบ จากนาฬิกานี้ (ใช้ได้กับสถานะ Compose เท่านั้น)
รอเงื่อนไข
เงื่อนไขใดๆ ที่ขึ้นอยู่กับงานภายนอก เช่น การโหลดข้อมูลหรือการวัดหรือวาดของ Android (นั่นคือ การวัดหรือวาดภายนอก Compose) ควรใช้แนวคิดที่ทั่วไปกว่า เช่น waitUntil()
composeTestRule.waitUntil(timeoutMs) { condition }
นอกจากนี้ คุณยังใช้waitUntil
ตัวช่วยต่อไปนี้ได้ด้วย
composeTestRule.waitUntilAtLeastOneExists(matcher, timeoutMs)
composeTestRule.waitUntilDoesNotExist(matcher, timeoutMs)
composeTestRule.waitUntilExactlyOneExists(matcher, timeoutMs)
composeTestRule.waitUntilNodeCount(matcher, count, timeoutMs)
แหล่งข้อมูลเพิ่มเติม
- ทดสอบแอปใน Android: หน้า Landing Page หลักของการทดสอบ Android จะให้มุมมองที่กว้างขึ้นเกี่ยวกับพื้นฐานและเทคนิคการทดสอบ
- หลักพื้นฐานของการทดสอบ: ดูข้อมูลเพิ่มเติม เกี่ยวกับแนวคิดหลักเบื้องหลังการทดสอบแอป Android
- การทดสอบในเครื่อง: คุณสามารถเรียกใช้การทดสอบบางอย่าง ในเครื่องบนเวิร์กสเตชันของคุณเองได้
- การทดสอบแบบมีเครื่องควบคุม: คุณควรเรียกใช้การทดสอบแบบมีเครื่องควบคุมด้วย กล่าวคือ การทดสอบที่ทำงานโดยตรง ในอุปกรณ์
- การรวมอย่างต่อเนื่อง: การรวมอย่างต่อเนื่องช่วยให้คุณผสานรวมการทดสอบเข้ากับไปป์ไลน์การติดตั้งใช้งานได้
- ทดสอบขนาดหน้าจอต่างๆ: เนื่องจากผู้ใช้มีอุปกรณ์ให้เลือกมากมาย คุณจึงควรทดสอบขนาดหน้าจอต่างๆ
- Espresso: แม้ว่า Espresso จะมีไว้สำหรับ UI ที่อิงตาม View แต่ความรู้เกี่ยวกับ Espresso ก็ยังเป็นประโยชน์สำหรับบางแง่มุมของการทดสอบ Compose