TDD คืออะไร และเป้าหมายคืออะไร

TDD หรือ Test-Driven Development คือการเริ่มจากเขียน test ที่สะท้อน behavior ที่ต้องการก่อน แล้วค่อยเขียนโค้ดให้ test ผ่าน เป้าหมายหลักคือได้ feedback เร็ว ลด regression และทำให้ design ของโค้ดบังคับตัวเองให้แยกความรับผิดชอบชัดขึ้น

วงจร Red → Green → Refactor

รอบทำงานของ TDD มักสั้นและชัดเจน: Red เขียน test ให้ fail ก่อนเพื่อยืนยันว่า test จับสิ่งที่เราต้องการได้จริง, Green เขียนโค้ดขั้นต่ำให้ test ผ่าน, และ Refactor ปรับปรุงโครงสร้างโค้ดโดยยังคงให้ test ผ่านทั้งหมด

ตัวอย่างจังหวะทำงานในงานจริง

สมมติเราต้องเพิ่มเงื่อนไขส่วนลดสมาชิก: เริ่มจากเขียน test ว่า member level ใดควรได้ส่วนลดเท่าไร (Red), จากนั้น implement logic ให้ผ่านเฉพาะเคสนี้ (Green), แล้วค่อยแยก logic คำนวณออกเป็น function ที่อ่านง่ายและนำกลับมาใช้ซ้ำได้ (Refactor)

ข้อดีและข้อควรระวัง

ข้อดีของ TDD คือช่วยให้ทีมกล้าเปลี่ยนโค้ดมากขึ้นเพราะมี safety net และช่วยปรับ API ให้ใช้งานง่ายจากมุมมองผู้ใช้โค้ด แต่ถ้าเขียน test ที่ผูกกับ implementation detail มากเกินไป จะทำให้ refactor ยากและเกิด test ที่เปราะได้

• โฟกัส behavior ที่มีคุณค่าต่อผู้ใช้หรือธุรกิจ
• หลีกเลี่ยงการ assert รายละเอียดภายในที่ไม่ใช่ contract
• รักษารอบ Red-Green-Refactor ให้สั้นเพื่อ feedback ที่เร็ว

เมื่อไรควรเริ่มใช้ TDD ในทีม

เริ่มได้จากงานขนาดเล็กที่มี rule ชัดเจนก่อน เช่น utility, pricing rule, validation, หรือ logic mapping จากนั้นค่อยขยายไปส่วนที่ซับซ้อนขึ้นเมื่อทีมเริ่มคุ้นกับจังหวะการทำงานแบบ test-first