ในบทความนี้ คุณจะได้ทราบวิธีใช้ API การทดสอบ waitUntil ใน Compose เพื่อรอให้ตรงตามเงื่อนไขบางอย่าง ซึ่งเป็นทางเลือกที่ดีแทนการใช้ทรัพยากรที่ไม่มีการใช้งานในบางสถานการณ์

[อัปเดตปี 2023] สรุป: ใช้ waitUntil API ใหม่เพื่อซิงค์ในการทดสอบ Compose (v1.4.0 ขึ้นไป)

การซิงค์คืออะไร

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

กด Enter หรือคลิกเพื่อดูรูปภาพแบบเต็มขนาด

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

กด Enter หรือคลิกเพื่อดูรูปภาพแบบเต็มขนาด

androidx.test และการทดสอบการเขียนจะใช้เทคนิคบางอย่างเบื้องหลังเพื่อให้คุณไม่ต้องกังวลเรื่องนี้มากนัก เช่น หากเทรดหลักทำงานอยู่ การทดสอบจะหยุดชั่วคราวจนกว่าจะดำเนินการในบรรทัดถัดไปได้

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

ตัวเลือกที่ 1: ทรัพยากรที่ไม่ได้ใช้งาน

Idling Resources เป็นฟีเจอร์ของ Espresso ที่ช่วยให้คุณซึ่งเป็นนักพัฒนาแอปตัดสินใจได้ว่าเมื่อใดที่แอปทำงานหนัก คุณใช้ฟีเจอร์นี้ได้ 2 วิธีดังนี้

1. ติดตั้งในเฟรมเวิร์กหรือไลบรารีที่ทำงานซึ่งการทดสอบมองไม่เห็น

ตัวอย่างที่ดีในเรื่องนี้คือ RxIdler ซึ่งจะห่อหุ้มตัวกำหนดเวลา RxJava นี่เป็นวิธีที่แนะนำในการลงทะเบียนทรัพยากรที่ไม่มีการใช้งาน เนื่องจากช่วยให้คุณแยกการตั้งค่าการทดสอบออกจากโค้ดทดสอบได้อย่างชัดเจน

2. การแก้ไขโค้ดภายใต้การทดสอบเพื่อแสดงข้อมูลอย่างชัดเจนว่าแอปของคุณทำงานอยู่หรือไม่

ตัวอย่างเช่น คุณอาจแก้ไขที่เก็บ (หรือการทดสอบแบบคู่) เพื่อระบุว่ากำลังทำงานขณะโหลดข้อมูลจากแหล่งข้อมูล

ซึ่งไม่ใช่วิธีที่ดีเนื่องจากคุณกำลังทำให้โค้ดที่ใช้งานจริงเสียหาย หรือสร้างการทดสอบที่ซับซ้อน และในบางกรณีก็ติดตั้งได้ยาก เช่น คุณจะใช้ Idling Resources ใน Kotlin Flow อย่างไร การอัปเดตใดเป็นครั้งสุดท้าย

แต่เราสามารถรอได้

ตัวเลือกที่ 2: การรออย่างผิดวิธี

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

การทดสอบนี้จะทำงานช้ากว่าที่จำเป็นหรือล้มเหลว เมื่อมีการทดสอบ UI หลายร้อยหรือหลายพันรายการ คุณก็ต้องการให้การทดสอบทำงานได้เร็วที่สุด

นอกจากนี้ บางครั้งโปรแกรมจำลองหรืออุปกรณ์อาจทำงานผิดปกติและเกิดอาการกระตุก ซึ่งทำให้การดำเนินการใช้เวลานานกว่า 2,000 มิลลิวินาทีเล็กน้อยและทำให้บิลด์ของคุณใช้งานไม่ได้ เมื่อคุณมีการทดสอบหลายร้อยรายการ ปัญหานี้จะกลายเป็นปัญหาใหญ่

ตัวเลือกที่ 3: รออย่างถูกวิธี

หากไม่ต้องการแก้ไขโค้ดภายใต้การทดสอบเพื่อแสดงเมื่อโค้ดทำงานหนัก อีกทางเลือกหนึ่งคือการรอจนกว่าจะตรงตามเงื่อนไขที่กำหนดแทนที่จะรอเป็นระยะเวลาที่กำหนดโดยพลการ

ใน Compose คุณสามารถใช้ประโยชน์จากฟังก์ชัน waitUntil ซึ่งรับฟังก์ชันอื่นที่สร้างบูลีน

อัปเดต 22/03/2023: ตั้งแต่ Compose 1.4.0 เป็นต้นไป เราได้เพิ่มชุด API waitUntil ใหม่ ดังนี้

[ก่อน 1.4.0: ใช้ตัวช่วยเหล่านี้: waitUntilExists, waitUntilNodeCount]

…และใช้ดังนี้

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

แล้วคุณควรใช้เมื่อใด กรณีการใช้งานที่ดีคือการโหลดข้อมูลจาก Observable (ด้วย LiveData, Kotlin Flow หรือ RxJava) เมื่อ UI ต้องได้รับการอัปเดตหลายครั้งก่อนที่คุณจะถือว่าไม่มีการใช้งาน คุณอาจต้องการลดความซับซ้อนของการซิงค์โดยใช้ waitUntil

ตัวอย่างเช่น เมื่อรวบรวมโฟลว์จากมุมมอง

และส่งหลายรายการไปยังสตรีมนั้น

หาก repository ใช้เวลานานเท่าใดก็ได้ในการแสดงผลลัพธ์แรก เฟรมเวิร์กการทดสอบจะถือว่า "กำลังโหลด" เป็นสถานะว่าง (ค่าเริ่มต้นที่กำหนดใน collectAsState) และดำเนินการต่อด้วยคำสั่งถัดไป

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

ขอให้สนุกกับการ… รอก่อนนะ… ทดสอบ

ใบอนุญาตข้อมูลโค้ด:

Copyright 2022 Google LLC.
SPDX-License-Identifier: Apache-2.0