ในการพัฒนาซอฟต์แวร์แบบดั้งเดิม เรามักจะเขียนโค้ดจนเสร็จก่อนแล้วค่อยเขียน Unit Test ตามหลัง แต่ Test-Driven Development กลับด้านกระบวนการนั้นโดยสิ้นเชิง TDD คือแนวคิดที่ว่า “เราต้องเขียนแบบทดสอบ ก่อนเริ่มเขียนฟีเจอร์จริง”
วัฏจักร Red-Green-Refactor
หัวใจสำคัญของ TDD ประกอบด้วย 3 ขั้นตอนสั้น ๆ ที่วนซ้ำไปเรื่อย ๆ จนกว่าจะได้ซอฟต์แวร์ที่สมบูรณ์
- 🔴 Red : เขียนแบบทดสอบสำหรับฟีเจอร์ใหม่ที่คุณต้องการ โดยที่ยังไม่มีโค้ดจริงรองรับ เมื่อรัน Test ผลลัพธ์จะต้อง “ไม่ผ่าน” เสมอ เพื่อยืนยันว่า Test นั้นทำงานได้จริงและตรวจพบจุดที่ยังไม่มีโค้ด
- 🟢 Green : เขียนโค้ดจริงด้วยวิธีที่เรียบง่ายที่สุด เป้าหมายเดียวในขั้นนี้คือทำให้ Test ที่เพิ่งเขียนไปเปลี่ยนสถานะเป็น “ผ่าน”
- 🔵 Refactor : เมื่อโค้ดทำงานถูกต้องแล้ว เราจะกลับมาปรับแต่งโครงสร้างโค้ด ให้สะอาด อ่านง่าย และมีประสิทธิภาพมากขึ้น โดยที่มี Test เป็น “ตาข่ายนิรภัย” คอยเช็คว่าการแก้ไขของเราไม่ได้ไปทำให้อะไรพัง
ทำไมเราถึงควรใช้ TDD ?
- ความมั่นใจในการแก้ไข : เมื่อคุณมี Test ครอบคลุมทุกส่วน คุณจะกล้าแก้ไขโค้ดเก่าหรือเพิ่มฟีเจอร์ใหม่ เพราะถ้าคุณพลาด Test จะเตือนคุณทันที
- ลดข้อผิดพลาด : เนื่องจากการเขียน Test ก่อนบังคับให้คุณต้องคิดถึง Error หรือ Edge Case ต่าง ๆ ล่วงหน้า ทำให้โอกาสที่ Bug จะหลุดไปถึง Production น้อยลงมาก
- โค้ดมีคุณภาพดีขึ้น : การเขียน Test ก่อนบังคับให้โค้ดของคุณต้อง “Testable” ซึ่งมักจะนำไปสู่การออกแบบที่เป็น Modular แยกส่วนชัดเจน และไม่ผูกติดกันจนเกินไป
- เป็นเอกสารที่มีชีวิต : โค้ดของ Test จะทำหน้าที่บอกนักพัฒนาคนอื่น ว่าฟังก์ชันนี้ทำงานอย่างไรและคาดหวังผลลัพธ์แบบไหน
ข้อควรระวังและการเริ่มต้น
แม้ TDD จะดูดีในทฤษฎี แต่ในทางปฏิบัติมีสิ่งที่ต้องพิจารณา
- ใช้เวลาในช่วงแรกนาน: การเขียน Test ก่อนอาจทำให้รู้สึกว่างานเดินช้าลงในช่วงเริ่มต้น
- ต้องอาศัยวินัย: เป็นเรื่องง่ายมากที่จะกลับไปเขียนโค้ดก่อนแล้วค่อยเขียน Test ตามหลัง
คำแนะนำสำหรับการเริ่มต้น
เริ่มจากโปรเจกต์เล็ก ๆ หรือฟังก์ชันที่มี Logic ซับซ้อน เพื่อให้เห็นประโยชน์ของการมี Test คอยตรวจสอบความถูกต้อง แล้วคุณจะพบว่าเวลาที่เสียไปกับการเขียน Test นั้น คุ้มค่ากว่าการต้องมานั่งแก้ Bug มหาศาลในภายหลังครับ
อ่านเพิ่มเติม