The Chromium Chronicle #2: ความไม่สม่ำเสมอในการทดสอบการต่อสู้

ตอนที่ 2: โดย Vasilii ในมิวนิก (พฤษภาคม 2019)
ตอนก่อนหน้า

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

ขั้นตอนการคัดแยก

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

ขั้นตอนการแก้ไขข้อบกพร่อง

แฟล็กบรรทัดคำสั่งหลายรายการมีประโยชน์ในการแก้ไขการทดสอบที่ไม่น่าเชื่อถือ เช่น --enable-pixel-output-in-tests จะแสดง UI จริงของเบราว์เซอร์

มีเครื่องมือสำรอง หากโปรแกรมแก้ไขข้อบกพร่องทำให้ความไม่สม่ำเสมอหายไป เป็นไปได้ว่าภายใต้โปรแกรมแก้ไขข้อบกพร่อง การทดสอบไม่เคยเป็นข้อผิดพลาด ในกรณีนี้ คุณควรใช้คำสั่งบันทึกหรือ base::debug::StackTrace แทน

ไม่ควรทำ

โปรดทราบว่าสาเหตุทั่วไปที่ทำให้EXPECT__* ทำงานไม่สำเร็จนอกเหนือจากข้อบกพร่องในโค้ดเวอร์ชันที่ใช้งานจริงมีดังนี้

  • ความคาดหวังไม่ถูกต้อง (เช่น หน้าที่ปลอดภัยหมายถึง HTTPS อาจเป็น localhost แทน)
  • เงื่อนไขการแข่งขันเนื่องจากการทดสอบไม่รอเหตุการณ์ที่เหมาะสม

[อย่าทดสอบการใช้งาน][not-implementation] แต่ทดสอบที่ลักษณะการทำงาน

// It takes 2 round trips between the UI and the background thread to complete.
SyncWithTheStore();
SyncWithTheStore();
CheckTheStore();

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

ไม่ควรทำ

โปรดระวังรูปแบบที่พบได้บ่อยดังตัวอย่างต่อไปนี้

Submit TestPasswordForm();
// Wait until things settle down.
RunLoop().RunUntilIdle();
CheckCredentialPromptVisible();

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

ควรทำ

วิธีแก้ไขที่ถูกต้องมีดังนี้

SubmitTestPasswordForm();
WaitUntilCredentialPromptVisible();

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

หลังการแก้ไข

เมื่อแก้ไขแล้ว ให้ทำการทดสอบหลายร้อยครั้งในเครื่อง คอยตรวจสอบพอร์ทัล Flakiness