TDD

RED → GREEN → Refactor

ขั้นตอนของ TDD นั้นเรียบง่ายมาก

ขั้นแรก ให้เขียน Test เพื่อกำหนดพฤติกรรมที่คาดหวังของฟีเจอร์ที่กำลังจะ Implement ซึ่งแน่นอนว่า Test จะต้องล้มเหลวก่อน (RED) จากนั้นเขียนโค้ดขั้นต่ำที่จำเป็นเพื่อให้ Test ผ่าน (GREEN) และสุดท้ายจัดระเบียบโค้ดโดยไม่เปลี่ยนแปลงพฤติกรรม (Refactor) ทำซ้ำ 3 ขั้นตอนนี้ในรอบสั้น ๆ ประมาณไม่กี่นาทีถึงสิบกว่านาที

Test ในฐานะเครื่องมือออกแบบ

หากมองว่า TDD เป็นเพียง "วิธีการทดสอบ" ก็จะเข้าใจสาระสำคัญผิดไป การเขียน Test ก่อนจะทำให้ Interface ของฟังก์ชัน (Arguments และ Return Value) ถูกกำหนดขึ้นก่อนที่จะเริ่ม Implement จริง เนื่องจากเป็นการออกแบบ API จากมุมมองของผู้เรียกใช้งาน จึงทำให้ Interface ที่ใช้งานยากเกิดขึ้นได้ยาก แรงจูงใจที่ Kent Beck เสนอแนวคิด TDD ก็ไม่ได้มาจากการเพิ่ม Test Coverage แต่มาจากการปรับปรุงคุณภาพของการออกแบบ

การใช้งานร่วมกับ Unit Test

Test ส่วนใหญ่ที่เขียนใน TDD จะเป็น Unit Test อย่างไรก็ตาม TDD คือ Methodology ที่ตอบคำถามว่า "จะเขียน Test เมื่อไหร่" ในขณะที่ Unit Test คือเรื่องของ Scope ที่ตอบคำถามว่า "จะทดสอบอะไร" ภายใน Cycle ของ TDD อาจมีการเขียน Test ที่เทียบเท่า Functional Test ได้ และในทางกลับกัน ก็สามารถเขียน Unit Test โดยไม่ใช้ TDD ก็ได้เช่นกัน

ความสัมพันธ์เชิงเสริมกับ ATDD

หาก ATDD ทำหน้าที่รับประกันความถูกต้องของ Business Requirement จากภายนอก TDD ก็ทำหน้าที่สั่งสมความถูกต้องของ Internal Implementation จากภายใน ในระดับโปรเจกต์โดยรวม โครงสร้างสองชั้นที่เหมาะสมคือการใช้ ATDD เพื่อกำหนด Acceptance Criteria และใช้ TDD เพื่อ Implement ฟังก์ชันแต่ละตัวให้ตรงตามเกณฑ์ดังกล่าว