อยาก test-drive โค้ดแตติด อาจไม่แน่ใจ interface ของ object จะเป็นยังไง อาจหลุดโฟกัสจากวันที่แจ่มใส ไม่แน่ใจว่าจะทดสอบสิ่งที่จะสร้างได้ไหม หรือเลื่อนลอยเพราะไม่อยากเขียนทดสอบ จะได้ประโยชน์จาก TDD ยังไงตอนไม่อยากทำ TDD?
Prototyping: สร้างแบบร่างเพื่อทิ้ง
"เมื่อใช้คอนเซปต์ระบบใหม่หรือเทคโนโลยีใหม่ ต้องสร้างระบบเพื่อทิ้ง เพราะแม้วางแผนดีที่สุดก็ไม่ได้ถูกต้องครั้งแรก วางแผนทิ้งหนึ่งครั้ง คุณจะทำอยู่ดี" – Fred Brooks
ตอนเริ่มฟีเจอร์ใหม่ ผมมักล้มเหลวตอนคิดจะเขียนทดสอบตัวแรก มีการตัดสินใจเยอะมากเกี่ยว API patterns practices และการรวมกัน
มีหลายวิธีเริ่มต้นตอนติด การสร้าง prototype เป็นอีกวิธีหนึ่ง
ตอนเขียน prototype คิดเหมือนวาดแบบร่าง Brainstorm ลองทำ ดิ้นๆทดสอบหรือ TDD ก่อน แทนที่จะตัดสินใจยาก ลอง patterns ใดๆ ดูว่าตรงกับฟีเจอร์ไหน หาจุดอ่อน จุดที่คิดมากเกินไป
จากนั้นทิ้งมัน สร้างใหม่ ครั้งนี้用 TDD และความรู้ใหม่เกี่ยวการสร้างฟีเจอร์ดีที่สุด
รู้ไหมตอนรัน git checkout -f ผิดพลาดหลังเขียนโค้ด รู้สึกถูกเตะท้อง? แตคิดว่าต้องสร้างอยู่ดี ลองใหม่ แล้วออกมาดีกว่าครั้งแรก? การ rebuild prototype ก็เช่นกัน ตอนมีไอเดียชัดเจน TDD จะง่ายขึ้นเยอะ
Reverse TDD
เคยเจอรู้สึกว่ารู้จะสร้างยังไงแต่ไม่รู้จะเขียนทดสอบก่อนไหม? หรือเปลี่ยนแค่บรรทัดเดียว แต่อาจต้องปรับ แล้วไม่อยากล็อกด้วยทดสอบก่อนรู้รูปแบบจริง?
กระบวนการง่ายช่วยได้มาก:
- เขียนโค้ดโดยไม่มีทดสอบ
- เขียนทดสอบสำหรับโค้ด ให้ผ่าน
- Comment out โค้ดที่เขียน หรือ revert ไฟล์
- รันทดสอบอีกครั้ง ให้ล้มเหลว
- เขียนโค้ดอีกครั้ง รันทดสอบ ให้ผ่าน
- Refactor โค้ด ใช้ประโยชน์จากทดสอบใหม่
เรียกว่า Reverse TDD หรือ Green-Red-Green-Refactor ไม่ได้ "test-driven design" แต่ยังเห็นทดสอบล้มเหลวตอนโค้ดเสีย สำคัญเพราะไม่น่าเชื่อถือทดสอบที่ไม่เคยล้มเหลวเลย
Reverse TDD ใช้ดีกับการเปลี่ยนเล็กๆ ไม่ต้องออกแบบมาก คิด bugfixes หรือเปลี่ยนใน method/class เดียว ผมใช้บ่อยมาก สำหรับการเปลี่ยนเล็กที่ยังลองผิดลองถูก
The Pairing Game
วิธีสนุกเพื่อหลุดจาก Red-Green-Refactor routine ตอนมีเพื่อนร่วมงาน:
- หาคู่หู
- คุณเขียนทดสอบที่จะล้มเหลว
- คู่หูพยายามแก้ด้วยโค้ดง่ายที่สุด
- คุณเขียนทดสอบอีกตัวที่ล้มเหลวกับโค้ดนั้น
- คู่หูเขียนโค้ดให้ผ่าน
- ทำซ้ำ…
- ตอนทดสอบผ่าน สลับ refactor แทนเขียนทดสอบ
- หลัง refactor สลับบทบาท tester และ coder
เล่าลับ: ผมเรียน TDD ตอนแรกจากการเล่น Pairing Game กับ bowling score calculator ช่วยฝึกเขียนโค้ดง่ายจากทดสอบล้มเหลว และเขียนทดสอบ เรียนรู้ coding style กัน และเข้าสู่ flow เร็ว รู้สึกดีตอนจบ
อาจผลิตโค้ดช้าลง แตสนุก เรียนรู้ดี
อยู่ในโหมดเล่นและทดลอง
TDD ไม่ควรเป็น dogma มีวิธีเล่นกับ core concepts นำไปสู่ที่น่าสนใจ โค้ดอาจดีกว่าเดิม
ลองทดลอง วิธีใหม่เขียนโค้ดและ TDD ดูความรู้สึกและโค้ดที่ออกมา ค้นหาความสนุกและ flow ในงานทุกวัน
