เทสต์เท่าไหร่ถึงเรียกว่าพอ

คำถามนี้โผล่ขึ้นมาทุกครั้งที่มีคนเสนอเพิ่มเทสต์ และคำตอบที่ได้ยินบ่อยที่สุดคือ "80% coverage" ซึ่งเป็นตัวเลขที่ฟังดูมีเหตุผลแต่ไม่ได้ตอบอะไรเลย

coverage บอกแค่ว่าโค้ดบรรทัดไหนถูกรันระหว่างเทสต์ ไม่ได้บอกว่าพฤติกรรมที่รันนั้นถูกหรือไม่ เทสต์ที่เรียกฟังก์ชันแล้วไม่ assert อะไรเลยก็นับ coverage ได้เต็ม ๆ

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

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

เริ่มตรงไหนถ้ามีเวลาจำกัด

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

สัดส่วนที่ใช้ได้จริง

สามเหลี่ยมเทสต์เป็นภาพที่รู้กันดี แต่สัดส่วนเป๊ะ ๆ ขึ้นกับงาน ถ้าทำ CRUD ธรรมดา unit เยอะ ๆ อาจเป็นภาระมากกว่าการเทสต์ทั้ง endpoint จริงจำนวนน้อย ๆ

ชนิด	เหมาะกับ	ข้อควรระวัง
Unit	ตรรกะที่มีเงื่อนไขเยอะ คำนวณ กฎธุรกิจ	mock มากเกินจนเทสต์กลายเป็นเทสต์ mock
Integration	การคุยกับฐานข้อมูลหรือระบบอื่น	ช้ากว่า ต้องเตรียมข้อมูลทดสอบ
End-to-end	เส้นทางหลักที่พังไม่ได้	เปราะและช้า ทำน้อยแต่ให้นิ่ง

สัญญาณว่าเทสต์มากเกินไป

แก้โค้ดนิดเดียวแล้วเทสต์แดง 30 ตัวโดยที่พฤติกรรมไม่ได้เปลี่ยน
ทีมเริ่มกลัวการ refactor เพราะต้องตามแก้เทสต์เยอะ
มีเทสต์ที่เขียนเพื่อดัน coverage โดยไม่มีใครอ่านมันอีกเลย

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

อยู่ในซีรีส์: ช่างฝีมือโค้ด

อ่านตอนต่อไป

ความคิดเห็น

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

เข้าสู่ระบบหรือสมัคร