| name | self-check |
| description | ตรวจงานก่อนบอกว่าเสร็จ — รัน เทสต์ หาบั๊ก แก้ แล้วค่อยจบ ใช้ทุกครั้งหลังทำงานโค้ด/สร้างไฟล์เสร็จ ก่อนสรุปว่าจบงาน |
Skill: self-check (ตรวจก่อนส่ง)
อย่าเพิ่งบอกว่า "เสร็จแล้ว" จนกว่าจะผ่านขั้นตอนนี้ — โค้ดที่ "ดูครบ" มักพังเงียบๆ ที่ edge case
ขั้นตอน
- นิยาม "ถูกต้อง" คืออะไร — ก่อนเทสต์ ระบุให้ชัดว่าผลลัพธ์ที่ถูกควรเป็นยังไง (ค่าที่คาด, พฤติกรรมที่ควรเกิด)
- รันจริง — รันโค้ด/ไฟล์/เทสต์ผ่าน bash. โค้ดที่รันไม่ได้ = ยังไม่เสร็จ
- เว็บ/JS:
node --check file.js เช็ค syntax ก่อน; แยก logic มารันใน node ได้
- Python: รันไฟล์ หรือ
python -m py_compile
- หาบั๊ก เชิงรุก — พยายามทำให้มันพัง:
- happy path (เคสปกติ) ✓
- edge case: ค่าว่าง, 0, ลบ, ใหญ่มาก, ซ้อนกัน, input แปลกๆ
- เคสที่ตรงข้ามกับที่ควร match/ทำงาน (ควรได้ false/error)
- เทียบ ground truth ถ้ามี — ถ้ามีของอ้างอิง (ผลที่รู้ว่าถูก, library มาตรฐาน, spec) ให้รันเทียบ เช่น regex engine → เทียบ
RegExp จริง; คณิต → เทียบผลที่คำนวณมือ; parser → เทียบ output ที่คาด
- ตรวจว่า "ถูก" ไม่ใช่แค่ "รันได้" — output ที่ออกมาถูกต้องจริงไหม ไม่ใช่แค่ไม่ error
- เจอบั๊ก → แก้ (ดู skill debug) → เทสต์ใหม่ วนจนผ่าน
- สรุปตามจริง: บอกว่าเทสต์อะไรไป ผ่าน/ไม่ผ่านอะไร ถ้ามีจุดที่ยังไม่ชัวร์หรือ skip ให้บอกตรงๆ — อย่าเคลมว่า "เสร็จสมบูรณ์" ถ้ายังไม่ได้ตรวจ
กฎ
- งานที่ verify ไม่ได้ในเครื่อง (เช่น UI ต้องเปิดเบราว์เซอร์) → อย่างน้อยเช็ค syntax + แยก logic มาเทสต์ + บอกผู้ใช้ว่าส่วนไหนต้องลองเอง
- ถ้าผู้ใช้จะเอาไปใช้จริง อย่าส่งของที่ "น่าจะถูก" โดยไม่ตรวจ — รันให้เห็นก่อน
- จบงานที่ผ่านการตรวจแล้ว = พูดได้เต็มปากว่าเสร็จ; จบงานที่ไม่ได้ตรวจ = หลอกตัวเองและผู้ใช้
