สรุปข้อดีและข้อเสียของ Test Driven Development (TDD)

วันนี้มาแนะนำการพัฒนาระบบงานด้วยแนวคิด TDD (Test-Driven Development) จึงทำการสรุปข้อดีและข้อเสียของแนวคิดนี้ไว้นิดหน่อย เพื่อทำให้เข้าใจกันมากขึ้น

เริ่มต้นด้วยข้อดี

ทำให้เราเขียน code เท่าที่จำเป็นเท่านั้น ถ้าเราปฏิบัติตามกฏและแนวคิดของ TDD คือ เราจะไม่เขียน production code ใด ๆ ถ้า test ทั้งหมดทำงานไม่ผ่าน ถ้าต้องการเพิ่ม feature ให่เข้าไป ต้องเริ่มจากการเขียน test ก่อนเสมอ โดยที่ production code ต้องเป็น code ที่เรียบง่าย หรือเพียงพอที่ทำให้ test ผ่าน ซึ่งจะทำให้เราได้ production code ที่จำเป็นจริง ๆ เท่านั้น ทำให้ code แยกกันอย่างชัดเจน เนื่องจากเราเริ่มต้นจากการเขียน test ดังนั้นถ้าต้องการทดสอบได้ง่าย ๆ แล้ว code แต่ละส่วนต้องไม่ผูกมัดกันแน่นจนเกินไป code ส่วนไหนควรอยู่ด้วยกันก็ไม่จำเป็นต้องแยกออกจากกัน ทำให้ code อยู่เป็นสัดเป็นส่วน เป็นกลุ่มเป็นก้อน ซึ่งเรามักจะเรียกว่า modular นั่นเอง ทำให้ง่ายต่อการดูแลรักษา เมื่อ code แยกกันอยู่ในที่ที่มันควรจะอยู่ ทำให้เมื่อทำการเพิ่ม featureและแก้ไขแล้ว จะลดผลกระทบลงไปอย่างมาก ตลอดจนมีชุดของการทดสอบที่ครอบคลุม ทำให้เรามั่นใจได้ว่า สิ่งที่แก้ไขมันทำงานถูกต้องหรือไม่ ทำให้เรามั่นใจได้ว่า สิ่งที่แก้ไขมันกระทบการทำงานส่วนอื่น ๆ หรือไม่ ข้อดีอีกอย่างคือ ทำให้เรามีความมั่นใจเมื่อต้อง refactor code หรือการปรับปรุงโครงสร้างของ code ให้ดีขึ้น สิ่งที่ตามมาก็คือ Test Coverage ที่สูงขึ้น Test coverage คือค่าที่บอกว่า test ที่เขียนมานั้น ครอบคลุม production code มากน้อยเพียงใด ซึ่งมันทำให้เรามั่นใจได้มากขึ้น ว่า test ที่เราเขียนมันไปครอบคลุม code ส่วนไหนบ้าง หรือไม่ครอบคลุมส่วนไหนบ้าง และถ้าเขียน test ดี ๆ แล้ว มันจะเป็นเอกสารชั้นดีเลย เนื่องจากใน test นั้น จะทำการอธิบายว่า production code ทำงานอย่างไร ? production code ใช้งานอย่างไร ? production code มีพฤติกรรมการทำงานอย่างไรบ้าง ? สุดท้ายจะช่วยทำให้ลดการ debugging ลงไปเยอะมาก ๆ ลองถามตัวเราเองสิว่า ใช้เวลาไปกับการ debug เยอะไหม ? ใช้เวลากับการ copy ข้อความจากการ debug เพื่อไปค้นหาผ่าน internet เยอะไหม ? ทำการ debug บ่อยไหม ? ถ้าตอบว่าใช่ ลองมาเขียน test เพื่อทดสอบกันไหม เพื่อทำให้เราเห็นข้อผิดพลาดเหล่านั้น จากนั้นจึงลงมือแก้ไขต่อไป

ปิดด้วยข้อเสีย

ทุกสิ่งทุกอย่างเมื่อมีข้อดีก็ย่อมมีข้อเสียเช่นกัน มาดูกันว่ามีข้อเสียอะไรบ้าง TDD นั้นไม่ใช่จะช่วยเราเสมอไป ถ้าเราเองไม่เข้าใจปัญหาที่ต้องการจะแก้ไข แล้วพยายามเขียน test มันก็ไม่ได้ช่วยอะไรมาก เช่นถ้าเข้าใจผิดก็เขียน test ผิด ส่งผลให้เขียน production code ผิดเช่นกัน หรือการเขียน test ช่วยให้เราหาข้อผิดพลาดได้ง่ายขึ้น แต่ไม่ได้บอกว่า จะช่วยหาข้อผิดพลาดใน test นะ ในช่วงแรกของการเริ่มต้นจะช้ามาก ๆ เนื่องจากเราต้องคิดก่อนว่า จะทำอะไร ? จะแก้ไขปัญหาอะไร ? จะเขียนอย่างไร ? จะสร้างอะไรบ้าง ? จากนั้นจึงเริ่มลงมือเขียน test จากนั้นจึงเขียน production code ต่อไป และวนแบบนี้เรื่อยไป ทำให้บางครั้งต้องใช้เวลาที่เยอะขึ้นกับงานที่ง่าย ๆ ทุกคนในทีมจำเป็นต้องทำตามแนวคิด TDD ซึ่งไม่ง่ายเลย บ่อยครั้งทำให้เกิดข้อขัดแย้งและโต้เถียงกันได้ ดังนั้นก่อนอื่นควรทำให้ทุกคนในทีม เห็นความสำคัญของการเขียน test ก่อน เมื่อ requirement เปลี่ยน จำเป็นต้องดูแลรักษา test code ด้วยนะ สิ่งแรกที่ทำเมื่อ requirement เปลี่ยนคือ การแก้ไข test code ก่อน จากนั้นจึงแก้ไข production code ต่อไป ซึ่งทำให้ทุกคนมองว่า จะเป็นต้องใช้เวลามากขึ้นนั่นเอง  

วันนี้คุณเขียน test แล้วหรือยัง ?