ทำไมเป้าหมาย Code Coverage แบบ 100% ถึงเป็นเรื่องหลอกลวง (Anti-Pattern)

ในวงการพัฒนาซอฟต์แวร์ เรามักจะได้ยินคำกล่าวที่ว่า "โค้ดที่ดีต้องมี Automated Test และ Code Coverage ต้องถึง 80% หรือ 100%" ซึ่งในทางทฤษฎีนั้นฟังดูดีมาก แต่ในโลกแห่งความเป็นจริง การตั้งเป้าหมายแบบเหมาเข่ง (Flat Target) ให้ทุกบรรทัดในโปรเจกต์ต้องถูกเทสต์ มักจะนำไปสู่ผลลัพธ์ที่ตรงกันข้ามกับที่คาดหวัง

เมื่อทีมถูกบีบด้วย KPI ให้ทำ Coverage ถึง 80% นักพัฒนามักจะเลือกเขียนเทสต์ให้กับ "โค้ดที่เขียนเทสต์ง่าย" (เช่น Getter/Setter หรือฟังก์ชันบวกเลขธรรมดา) เพื่อปั่นตัวเลขให้ถึงเป้า แต่กลับละเลยโค้ดที่มีความซับซ้อนและสำคัญจริงๆ เพราะมันเขียนเทสต์ยากและใช้เวลานาน ปรากฏการณ์นี้เรียกว่า "Coverage Inflation" ซึ่งหลอกให้เรารู้สึกปลอดภัย ทั้งที่ระบบจริงๆ ยังเปราะบาง

Risk-based Testing คือคำตอบ

แทนที่จะพยายามเทสต์ทุกอย่าง เราควรเปลี่ยนมุมมองมาใช้ Risk-based Code Coverage หรือการกำหนดเป้าหมายการเทสต์ตามความเสี่ยงของแต่ละโมดูล (Module) โดยพิจารณาจาก 3 ปัจจัยหลัก ได้แก่:

• 1. ผลกระทบต่อธุรกิจ (Business Impact):
  โมดูลเกี่ยวกับการชำระเงิน (Payment Gateway) หรือการยืนยันตัวตน (Authentication) หากเกิดบั๊กขึ้นมา อาจทำให้บริษัทเสียรายได้มหาศาลหรือเสียชื่อเสียง โมดูลกลุ่มนี้ควรตั้งเป้า Coverage ไว้ที่ 90-100% และเขียนเทสต์ให้ครอบคลุมทุก Edge Case ในขณะที่หน้า UI ภายในหลังบ้าน (Admin Dashboard) อาจจะมี Coverage แค่ 30-40% ก็เพียงพอแล้ว
• 2. ความถี่ในการเปลี่ยนแปลง (Frequency of Changes):
  โค้ดที่ถูกแก้ไขบ่อย มีโอกาสสูงที่คนเข้ามาแก้ทีหลังจะเผลอทำพัง (Regression) โค้ดส่วนนี้จึงจำเป็นต้องมี Automated Test ที่รัดกุมคอยเป็นตาข่ายรองรับ (Safety Net) ส่วนโค้ดประเภท Boilerplate หรือ Configuration ที่เขียนครั้งเดียวแล้วไม่เคยแก้อีกเลยเป็นปีๆ การเสียเวลาเขียน Unit Test ให้มันอาจจะไม่คุ้มค่าแรง
• 3. ความซับซ้อน (Code Complexity):
  หากคุณมีฟังก์ชันที่รับพารามิเตอร์ 5 ตัว และมี if-else ซ้อนกันหลายชั้น (High Cyclomatic Complexity) มนุษย์จะไม่สามารถจำลองสถานการณ์ทั้งหมดในหัวได้หมด ฟังก์ชันแบบนี้จำเป็นต้องใช้ Unit Test เข้ามาช่วยยืนยันความถูกต้อง ส่วนฟังก์ชันง่ายๆ ที่อ่านบรรทัดเดียวก็รู้เรื่อง การเขียนเทสต์อาจจะไม่ได้เพิ่มมูลค่าเท่าไหร่นัก

วิธีนำแนวคิดนี้ไปปรับใช้ในทีม

เริ่มต้นโดยการแบ่งโปรเจกต์ของคุณออกเป็นส่วนๆ (Components/Modules) แล้วใช้เครื่องมือคำนวณด้านบนเพื่อประเมินเป้าหมาย Coverage ที่เหมาะสมสำหรับแต่ละส่วน จากนั้นในระบบ CI/CD ให้ตั้งค่าเกณฑ์ขั้นต่ำ (Threshold) แยกตามแฟ้มหรือโฟลเดอร์ แทนที่จะตั้งค่ารวมทั้งโปรเจกต์

จำไว้เสมอว่า Code Coverage เป็นเพียงเครื่องมือที่ช่วยบอกว่า "โค้ดส่วนไหนยังไม่ได้ถูกเทสต์" ไม่ใช่เครื่องมือที่บอกว่า "โค้ดที่เทสต์แล้วมีคุณภาพดีเยี่ยม" การมี Coverage 60% ที่เทสต์เฉพาะส่วนสำคัญที่สุด มีค่ามากกว่า Coverage 90% ที่เกิดจากการปั่นเทสต์ที่ไม่มีความหมายเลย