เขียนการทดสอบจะซิงค์กับ UI ของคุณโดยค่าเริ่มต้น เมื่อคุณเรียกใช้การยืนยันหรือการดำเนินการด้วย ComposeTestRule
ระบบจะซิงค์การทดสอบล่วงหน้าและรอจนกว่าต้นไม้ UI จะหยุดทำงาน
โดยปกติแล้วคุณไม่จำเป็นต้องดำเนินการใดๆ อย่างไรก็ตาม โปรดทราบว่ามีบางกรณีที่ควรทราบ
เมื่อการทดสอบซิงค์กัน แอป 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()
}
โปรดทราบว่าข้อกำหนดนี้มีผลบังคับใช้กับลำดับชั้นของการเขียนเท่านั้น และไม่ได้มีผลกับ ที่เหลือในแอปด้วย
ปิดใช้งานการซิงค์อัตโนมัติ
เมื่อคุณเรียกใช้การยืนยันหรือการดำเนินการผ่าน ComposeTestRule
เช่น
assertExists()
การทดสอบของคุณจะซิงค์กับ UI ของ Compose ในบางกรณี คุณอาจต้องการหยุดการซิงค์นี้และควบคุมนาฬิกาด้วยตนเอง สำหรับ
เช่น คุณสามารถควบคุมเวลาในการจับภาพหน้าจอของภาพเคลื่อนไหวที่ถูกต้องแม่นยำ
ซึ่ง UI จะยังคงไม่ว่าง หากต้องการปิดใช้การซิงค์อัตโนมัติ
ตั้งค่าพร็อพเพอร์ตี้ autoAdvance
ใน mainClock
เป็น false
:
composeTestRule.mainClock.autoAdvance = false
โดยปกติแล้ว คุณจะต้องกรอกเวลาด้วยตนเอง คุณสามารถเลื่อนไปได้ทีละ 1 ช่วงเท่านั้น
เฟรมที่มี advanceTimeByFrame()
หรือตามระยะเวลาที่กำหนดด้วย
advanceTimeBy()
:
composeTestRule.mainClock.advanceTimeByFrame()
composeTestRule.mainClock.advanceTimeBy(milliseconds)
ทรัพยากรที่ไม่มีการใช้งาน
คอมโพซสามารถซิงค์การทดสอบและ UI เพื่อให้การดําเนินการและการยืนยันทั้งหมดทําในสถานะ "ไม่มีการใช้งาน" โดยรอหรือเดินหน้านาฬิกาตามต้องการ อย่างไรก็ตาม การดำเนินการแบบอะซิงโครนัสที่ผลลัพธ์ที่มีผลต่อสถานะ UI นั้นสามารถเรียกใช้ได้ใน ขณะที่การทดสอบไม่ทราบเรื่องนั้นๆ
สร้างและลงทะเบียนทรัพยากรที่ไม่ได้ใช้งานในการทดสอบ เพื่อให้ระบบนำทรัพยากรเหล่านี้ไปใช้ ไว้พิจารณาเมื่อตัดสินว่าแอปที่กำลังทดสอบอยู่หรือไม่ได้ใช้งาน ไม่ได้นะ จะต้องดำเนินการเว้นแต่จะต้องลงทะเบียนทรัพยากรที่ไม่มีการใช้งานเพิ่มเติม ตัวอย่างเช่น หากคุณเรียกใช้งานเบื้องหลังที่ไม่ได้ซิงค์กับ Espresso หรือ เขียน
API นี้คล้ายกับ ทรัพยากรที่ไม่ได้ใช้งานของ Espresso มาก แต่จะระบุได้ว่ารายการทดสอบไม่ได้ใช้งานหรือใช้งานอยู่ ใช้กฎการทดสอบการเขียนเพื่อลงทะเบียนการใช้งาน IdlingResource
composeTestRule.registerIdlingResource(idlingResource)
composeTestRule.unregisterIdlingResource(idlingResource)
การซิงค์ด้วยตนเอง
ในบางกรณี คุณต้องซิงค์ UI ของเครื่องมือเขียนอีเมลกับส่วนอื่นๆ ของการทดสอบหรือแอปที่คุณทดสอบ
ฟังก์ชัน waitForIdle()
จะรอให้ไม่มีความเคลื่อนไหวในการเขียน แต่ฟังก์ชันนี้
ขึ้นอยู่กับพร็อพเพอร์ตี้ 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 }
โปรดทราบว่าเงื่อนไขที่ระบุควรตรวจสอบสถานะที่ได้รับผลกระทบจากนาฬิกานี้ (ใช้ได้กับสถานะ "เขียน" เท่านั้น)
รอเงื่อนไข
เงื่อนไขที่ขึ้นอยู่กับงานภายนอก เช่น การโหลดข้อมูลหรือ
วัดหรือวาด (วัดหรือวาดภายนอกการเขียน) ควรใช้
แนวคิดทั่วไปเพิ่มเติม เช่น 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: เหมาะสำหรับข้อมูลในมุมมอง UI, ความรู้เกี่ยวกับ Espresso ยังมีประโยชน์สำหรับ Compose ในบางแง่มุม การทดสอบ