Vitest · Test ที่เชื่อถือได้
Happy Path และ Edge Case
เปลี่ยน requirement ให้เป็นกรณีปกติและกรณีขอบที่ควรทดสอบ
เริ่มจาก behavior ที่ requirement สัญญา
Happy path คือกรณีใช้งานปกติที่ input ถูกต้องและ flow ควรสำเร็จ ส่วน edge case คือกรณีขอบที่ยังอยู่ในขอบเขต requirement เช่น รายการว่าง, id ไม่พบ หรือ title เป็นช่องว่าง การเขียน test ไม่ใช่การสุ่มสร้าง input แปลก ๆ แต่คือการแปลงกติกาของระบบเป็นกรณีที่ตรวจได้
| ชนิดกรณี | ตัวอย่าง Task service | สิ่งที่ควรตรวจ |
|---|---|---|
| Happy path | ค้นหา id ที่มีอยู่ | คืน Task ที่ตรง id |
| Edge case | ค้นหา id ที่ไม่มีอยู่ | คืน undefined ตาม contract |
| Invalid input | สร้าง Task ด้วย title ว่าง | throw error ถ้า requirement กำหนดไว้ |
เห็นความต่างของ happy path กับ edge case
ให้เริ่มจาก contract ของ function แล้วถามว่า input แบบปกติคืออะไร และมีขอบเขตใดที่ทำให้ behavior เปลี่ยน ตัวอย่างนี้ไม่ได้สุ่มสร้าง test หลายข้อ แต่เลือกสองกรณีที่ตอบคนละคำถาม
| กรณี | คำถามที่ test ต้องตอบ |
|---|---|
| มี id อยู่ | ค้นหาแล้วคืน Task ที่ตรงกันหรือไม่ |
| ไม่มี id อยู่ | ค้นหาแล้วคืน undefined ตาม contract หรือไม่ |
ไม่ต้อง test ทุกค่าที่เป็นไปได้
กฎสำคัญ
เลือก case ที่เปลี่ยน behavior
ถ้า input หลายค่าทำให้ function ใช้กติกาเดียวกัน ให้เลือกตัวแทนที่อ่านง่าย
หนึ่ง case ต้องมีเหตุผล
เขียนชื่อหรือ comment ให้รู้ว่ากรณีนี้ป้องกัน requirement ข้อใด
อย่าเพิ่ม edge case นอกสัญญา
ถ้า requirement ยังไม่พูดถึง input นั้น อย่าให้ test บังคับ implementation ให้รองรับโดยไม่มีการตัดสินใจ
ครบถ้วนไม่เท่ากับจำนวน test เยอะ
ชุด test ที่ดีครอบคลุม behavior สำคัญและทำให้คนแก้โค้ดรู้ผลกระทบ ไม่ใช่ชุดที่มีกรณีจำนวนมากแต่ไม่มีคำถามชัดเจน
แบบฝึก: แตก requirement เป็น cases
เขียน test case ที่จำเป็นสำหรับ function ค้นหา Task
งานที่ต้องทำ
- เขียน happy path เมื่อ id มีอยู่
- เขียน edge case เมื่อ id ไม่อยู่
- ระบุ expected result ของแต่ละกรณี
ลองทำด้วยตัวเองก่อน แล้วค่อยเปิดเฉลยเพื่อเทียบแนวคิดและรายละเอียด