วันนี้มาแนะนำการพัฒนาระบบงานด้วยแนวคิด 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 แล้วหรือยัง ?
