การรีแฟกเตอร์โค้ดที่ทำให้ CI/CD ผ่านฉลุยโดยไม่ตรวจอะไร
นักพัฒนาแชร์อุทาหรณ์การจัดระเบียบโค้ดสคริปต์ deploy ที่เผลอย้ายจุดตรวจสอบ Validation ทำให้ระบบผ่านการทดสอบทั้งหมดโดยไม่ได้ตรวจสอบความถูกต้องจริง
ภาพประกอบจากคลังภาพสต็อก ไม่ใช่ภาพจากเหตุการณ์จริง
- การรีแฟกเตอร์โค้ดเพื่อความสะอาดตาอาจเผลอย้ายจุดตรวจสอบความถูกต้องจนใช้งานไม่ได้
- ฟังก์ชัน build_workspace() ทำหน้าที่ตรวจสอบผ่าน API แต่ถูกข้ามเพราะคำสั่ง return ก่อนเวลา
- ชุดทดสอบ (Test suite) ทั้งหมดผ่านเพราะตรวจสอบแค่การไม่มีผลside effect ไม่ใช่การมีอยู่จริงของการตรวจสอบ
- โค้ดที่ผ่านการตรวจสอบปลอมนี้อาจทำให้ข้อผิดพลาดหลุดรอดไปถึงกิ่ง release ได้อย่างง่ายดาย
การปรับปรุงโครงสร้างโค้ดหรือการรีแฟกเตอร์เพื่อความเรียบร้อยมักเป็นเรื่องปกติในหมู่โปรแกรมเมอร์ แต่บางครั้งการเปลี่ยนแปลงเล็กน้อยก็อาจซ่อนข้อผิดพลาดร้ายแรงไว้ได้ โดยนักพัฒนาจาก VedaForge ได้แชร์ประสบการณ์การพบ บั๊ก ที่ไม่ได้มาจากระบบทดสอบอัตโนมัติ แต่ถูกค้นพบโดยบังเอิญจากการอ่านส่วนต่าง (diff) ของโค้ดด้วยตาตนเอง ซึ่งเป็นข้อผิดพลาดที่ไม่มีชุดทดสอบใดสามารถตรวจจับได้
ปัญหาเกิดขึ้นในสคริปต์ deployment ที่มีโหมดการตรวจสอบความถูกต้อง (VALIDATE_ONLY=true) สำหรับกิ่ง develop ซึ่งถูกออกแบบมาเพื่อให้ระบบตรวจสอบทุกอย่างโดยไม่มีการเขียนข้อมูลจริงลงไป โค้ดเดิมจะทำการสร้าง workspace ก่อน จากนั้นจึงพิมพ์ข้อความแจ้งเตือนโหมดตรวจสอบ และออกจากโปรแกรมหากเป็นโหมดดังกล่าว แต่ด้วยความตั้งใจที่จะจัดระเบียบโค้ดให้ดูสะอาดตาขึ้น นักพัฒนาจึงได้สลับตำแหน่งคำสั่งตรวจสอบเงื่อนไขขึ้นมาก่อนการสร้าง workspace
ภาพประกอบจากคลังภาพสต็อก ไม่ใช่ภาพจากเหตุการณ์จริง
ผลลัพธ์ของการสลับตำแหน่งนี้ทำให้ฟังก์ชัน build_workspace() กลายเป็นโค้ดที่ไม่สามารถเข้าถึงได้ในโหมดตรวจสอบความถูกต้อง เนื่องจากระบบสั่ง return ออกจากฟังก์ชันไปเสียก่อน แต่หน้าตาของโค้ดกลับดูเป็นระเบียบเรียบร้อย ไม่มีส่วนไหนเขียนทับ workspace ในทั้งสองเวอร์ชัน และที่สำคัญคือ ชุดทดสอบทั้งหมดทำงานผ่านฉลุยอย่างไร้ที่ติ
เหตุการณ์นี้สะท้อนให้เห็นถึงจุดบอดคลาสสิกในการเขียน Unit Test สำหรับระบบ CI/CD โดยชุดทดสอบมักจะตรวจสอบผลลัพธ์เชิงลบ (เช่น การไม่มีการเผยแพร่ข้อมูล หรือการออกจากโปรแกรมอย่างสะอาด) แต่กลับละเลยการตรวจสอบว่ากระบวนการทำงานหลักที่จำเป็นต้องเกิดจริงๆ นั้นได้ถูกเรียกใช้งานหรือไม่ การทดสอบจึงบอกได้เพียงว่าโค้ดทำอะไรบ้าง แต่ตอบไม่ได้ว่าการตรวจสอบนั้นเกิดขึ้นจริงหรือถูกข้ามไปแล้ว
หัวใจสำคัญคือ build_workspace() ไม่ใช่โค้ดตั้งค่าธรรมเนียม แต่เป็นตัวกระบวนการตรวจสอบตัวเอง เนื่องจากการสร้างออบเจกต์ดังกล่าวจะทำหน้าที่ยืนยันตัวตน service principal, ค้นหาเป้าหมาย workspace ผ่าน API และแยกวิเคราะห์ (parse) ทุกรายการใน repository ซึ่งกระบวนการเหล่านี้คือขั้นตอนที่ตรวจพบข้อผิดพลาดส่วนใหญ่ เมื่อคำสั่ง return ถูกย้ายมาไว้ก่อนขั้นตอนนี้ ระบบจึงพิมพ์ข้อความแจ้งเตือนที่น่าไว้วางใจ ออกจากโปรแกรมด้วยรหัสศูนย์ และผ่านการสร้างบิลด์บนกิ่ง validation ไปได้โดยไม่ได้ตรวจสอบอะไรเลย ทำให้โค้ดที่มีข้อผิดพลาดหลุดรอดไปถึงกิ่ง release ได้อย่างไร้การสังเกต
"Built before the validate-only check on purpose. Constructing the FabricWorkspace authenticates, resolves the target workspace and parses every item, so it is the part that actually validates."
VedaForge Developer
ทางแก้ไขที่นักพัฒนาเลือกใช้คือการกู้คืนลำดับโค้ดเดิมกลับมา พร้อมทั้งเพิ่มคอมเมนต์อธิบายกำกับไว้อย่างชัดเจน แม้ว่าคอมเมนต์จะไม่ใช่เกราะป้องกันที่แข็งแกร่งที่สุด แต่การเขียนอธิบายไว้บรรทัดเดียวก็ดีกว่าการพยายามสร้างชุดทดสอบที่ซับซ้อนเพื่อตรวจสอบโหมดที่ถูกออกแบบมาให้ไม่ทำอะไรเลย
ที่มา: Dev.to
พบข้อมูลผิดพลาดในบทความนี้? แจ้งปัญหาบทความนี้
ความคิดเห็น
แสดงความคิดเห็น