A blank page and: ข้อผิดพลาดที่เอเจนต์มองไม่เห็น
บทความชุดเกี่ยวกับ @relax.js/core เผยปัญหาบั๊กไร้เสียงที่เอเจนต์เขียนโค้ดและทดสอบผ่าน แต่ส่งผลให้หน้าจอว่างเปล่า

ภาพประกอบจากคลังภาพสต็อก ไม่ใช่ภาพจากเหตุการณ์จริง
- การใช้งาน @relax.js/core ร่วมกับเอเจนต์เขียนโค้ดต้องเผชิญกับข้อผิดพลาดเงียบที่ไม่ส่งเสียงเตือน
- เอเจนต์มองเห็นหน้าเว็บผ่านผลการทดสอบเท่านั้น ทำให้พลาดบั๊กที่ทำให้หน้าจอขาวโพลน
- ฟังก์ชัน reportError() และ captureRelaxErrors() ช่วยดักจับข้อผิดพลาดเหล่านี้ในการทดสอบ
- เวอร์ชัน 1.8.0 ได้แก้ไขจุดบกพร่องที่เคยล้มเหลวโดยไม่มีการแจ้งเตือนหลายประการ
นี่คือบทความตอนที่สี่ในชุดบทความเกี่ยวกับการใช้ @relax.js/core ร่วมกับโค้ดดิ้งเอเจนต์ ซึ่งมุ่งเน้นไปที่ความล้มเหลวที่ไม่ส่งเสียงเตือนใดๆ โดยปัญหาหลักคือค่าเริ่มต้นที่ผิดพลาดสำหรับเอเจนต์ เนื่องจากมุมมองเดียวที่เอเจนต์มีต่อหน้าเว็บคือผลการทดสอบ มันจะเขียนคอมโพเนนต์ เขียนเทส รันมัน แล้วเห็นผลลัพธ์เป็นสีเขียวผ่านทั้งหมด แม้ว่าหน้าตาจริงของเว็บจะพังก็ตาม
ข้อผิดพลาดทุกตัวที่ไลบรารีตรวจพบจะผ่านฟังก์ชัน reportError() ซึ่งจะสร้าง RelaxError พร้อมข้อความและออบเจ็กต์บริบท แล้วส่งต่อให้กับแฮนเดอร์ที่ลงทะเบียนไว้ผ่าน onError() ในแอปพลิเคชัน แฮนเดอร์นี้จะบันทึกไปยังบริการของคุณหรือแสดงข้อความแจ้งเตือน ถ้าไม่มีการลงทะเบียนแฮนเดอร์ ข้อผิดพลาดจะยังคงถูกเก็บไว้ใน window.relaxErrors โดยจะเก็บบันทึก 50 รายการล่าสุด และตัวแรกที่ยังไม่ได้รับการจัดการจะพิมพ์ข้อความบรรทัดเดียวลงในคอนโซล

ภาพประกอบจากคลังภาพสต็อก ไม่ใช่ภาพจากเหตุการณ์จริง
เพื่อแก้ปัญหานี้ ฟังก์ชัน captureRelaxErrors() จาก @relax.js/core/testing จะทำการสลับไปใช้แฮนเดอร์ที่ทำหน้าที่รวบรวมข้อผิดพลาดแทนการโยนข้อผิดพลาดทิ้ง และคืนค่ากลับมาด้วยเมธอด restore() เมื่อช่องทางการสื่อสารนี้เกิดขึ้น ผู้เขียนจึงได้ตรวจสอบทุกสิ่งที่เคยล้มเหลวโดยไม่มีการแจ้งเตือนผ่านช่องทางนี้ ซึ่งบันทึกการเปลี่ยนแปลงของเวอร์ชัน 1.8.0 ได้รวบรวมรายการเหล่านั้นไว้ โดยมีสี่รายการที่ถูกนำไปใส่ไว้ในแอปพลิเคชันตัวอย่างในรูปแบบของการทดสอบ
ในบริบทของการพัฒนาซอฟต์แวร์สมัยใหม่ที่พึ่งพา AI หรือโค้ดดิ้งเอเจนต์มากขึ้น บั๊กที่ "ไม่มีเสียงเตือน" (Silent Failures) ถือเป็นความท้าทายที่อันตรายที่สุด เนื่องจากเครื่องมืออัตโนมัติมักจะวัดความสำเร็จจากรหัสผ่าน (Green Test) แต่ไม่สามารถรับรู้ประสบการณ์การใช้งานจริงของผู้ใช้ปลายทางได้ การสร้างกลไกดักจับข้อผิดพลาดระดับเอ็นจิ้นจึงเป็นสิ่งสำคัญที่จะช่วยปิดรอยต่อระหว่างการทดสอบในสภาพแวดล้อมจำลองและความเป็นจริง
นอกจากนี้ render() จะเปรียบเทียบออบเจ็กต์บริบทด้วยความเหมือนของตัวตน (Identity) หากมีการแก้ไขออบเจ็กต์แล้วเรนเดอร์ใหม่อีกครั้ง จะไม่มีอะไรเปลี่ยนแปลงเลยเนื่องจากฝั่งเอ็นจิ้นมองว่าไม่มีอะไรเกิดขึ้น ในขณะเดียวกัน เทมเพลตเอนจิ้นยังรองรับการตั้งค่า { strict: true } ซึ่งจะทำให้ข้อผิดพลาดของเทมเพลตทั้งหมดโยนข้อยกเว้นทันที แต่ผู้เขียนเลือกที่จะไม่ใช้มันในโค้ดแอปพลิเคชัน ด้วยเหตุผลที่ว่าข้อผิดพลาดจากการพิมพ์ผิดเพียงจุดเดียวไม่ควรทำให้หน้าจอของผู้ใช้กลายเป็นสีขาวว่างเปล่า
คำถามที่ยังคงหลงเหลืออยู่คือเอเจนต์ยังคงต้องเขียนเทสที่เรนเดอร์คอมโพเนนต์ด้วยโมเดลที่ถูกต้องและจดจำการเรียกใช้ capture ให้ได้ บทความตอนที่หกจะพูดถึงการจับข้อผิดพลาดจากการพิมพ์ผิดก่อนที่สิ่งใดจะถูกเรนเดอร์ขึ้นมา ก่อนหน้านั้นคือเรื่องของรอยต่อในการทดสอบ: วิธีที่เอเจนต์ดึงหน้าเว็บขึ้นมาแสดงผลบนหน้าจอโดยไม่ต้องใช้เบราว์เซอร์จริง
ที่มา: Dev.to
พบข้อมูลผิดพลาดในบทความนี้? แจ้งปัญหาบทความนี้
ความคิดเห็น
แสดงความคิดเห็น