Test Driven Development: TDD
ในปัจจุบันแนวโน้มของการเขียนโปรแกรมได้เปลี่ยนไปเป็นลักษณะที่ต้องรองรับความเปลี่ยนแปลงของ requirement ได้อย่างยืดหยุ่นมากขึ้น ไม่ว่าจะเป็นการแก้ไขส่วนงานเดิมหรือเพิ่มฟังก์ชันใหม่ๆ เข้ามาตัวอย่างเช่น facebookในทุกวันนี้ มีสิ่งที่เหมือน facebookในช่วงปีที่เปิดตัว แทบจะเหลือแค่สีฟ้าเท่านั้นเอง นอกนั้นเราจะเห็นการเพิ่ม function ใหม่ๆ เข้ามาอยู่เรื่อยๆ อันไหนดีก็คงไว้อันไหนไม่ค่อยเป็นที่นิยม ไม่กี่สัปดาห์เราก็จะเห็นมันหายไป สิ่งเหล่านี้เกิดจากการสร้างโปรแกรมในลักษณะที่เรียกว่า Agile Programming ซึ่งอาจจะถือได้ว่าเป็นปรัชญาการสร้างโปรแกรมที่อยู่คนละด้านกับการพัฒนาแบบ Water fall ในแบบเดิม
Agile Programming มองว่าความเปลี่ยนแปลงมีตลอดเวลา ไม่ว่าจะเป็นเทคโนโลยี หรือการตอบสนองของผู้ใช้งานหลังจากปล่อย version แรกไปแล้ว ดังนั้นการพัฒนาซอฟต์แวร์ตามเอกสารกระดาษที่เขียนไปแต่เริ่มแรกนั้นเป็นสิ่งที่แทบจะเป็นไปไม่ได้เลย และหลายครั้งสิ่งที่เป็นบริการใหม่ๆ ตัวลูกค้าเองก็ไม่ทราบว่าต้องการอะไรแน่จากซอฟต์แวร์จนกว่าจะได้ลงมือพัฒนาไปแล้ว ได้ทดลองใช้บ้างแล้ว แล้วมาปรับเปลี่ยนไปด้วยกัน
TDD ก็เป็นหนึ่งในวิธีการแบบ Agile
เป็นวิธีการพัฒนาซอฟต์แวร์วิธีหนึ่งโดยยึดหลักการที่ว่า "เตรียมทดสอบ ก่อนที่จะเขียนโค้ด"
วิธีการคือทำความเข้าใจกับความต้องการของสิ่งที่จะพัฒนา (User’s Requirement) โดยใช้ Use Case และ User Story จากนั้นแบ่ง requirement ของซอฟต์แวร์ออกเป็นส่วนย่อยๆเพื่อนำเข้าสู่กระบวนการพัฒนาแบบ Test-Driven มีขั้นตอน 5 ขั้นตอนดังนี้
- Add Test เป็นการสร้างการทดสอบแบบอัตโนมัติ (Automated Test Case) ของแต่ละส่วนย่อยๆ
- Watch Test Fail คือการลอง run test ดู และควรจะได้ผล "fail" เพราะเรายังไม่ได้เขียน code นั่นเอง
- Write Code ขั้นตอนนี้ก็ลงมือเขียน code โดยมีวัตถุประสงค์เพื่อให้ผ่าน Test Case ในข้อ 2
- Run Tests ถ้าหาก Test case ผ่านเมื่อใด ก็ถือว่าพัฒนาสำเร็จ สามารถทำงานได้ตามต้องการ
- Refactorทำการปรับแต่ง code เช่น clean up หรือ tune ประสิทธิภาพ
TDD มีข้อดีคือผู้พัฒนาจะพัฒนาโดยมีความเข้าใจถึงผลลัพธ์สุดท้ายที่ต้องการอยู่ในใจเสมอและที่สำคัญคือผลลัพธ์นั้นจะเป็นสิ่งที่ลูกค้าเห็นและเข้าใจตรงกันด้วยนอกจากนั้นการแบ่งการทดสอบเป็นส่วนย่อยๆ ยังทำให้สามารถ roll back ได้ง่ายหากโปรแกรมเกิดความผิดพลาดหรือพัฒนาแล้วใช้ไปแล้วไม่ชอบใจ และด้วยลักษณะที่เน้นให้โปรแกรมผ่าน Test Case ก่อน แล้วค่อยมาปรับแต่งที่หลังทำให้การพัฒนารวดเร็วขึ้น เช่นถ้าหากมีส่วนต่อไปที่รอการพัฒนาอยู่ ก็สามารถทำต่อไปได้เลยในขณะที่ส่วนแรกกำลังทำการปัดกวาดในขั้นตอน Refactor
และแน่นอน ทุกอย่างย่อมมีทั้งข้อดีและข้อเสีย สำหรับข้อเสียของ TDD ก็คือหากแบ่งส่วนของโปรแกรมไม่เหมาะสม เช่น ย่อยเกินไปก็จะเสีย overhead ในการสร้าง automated test case เยอะ และถ้าหากแบ่งส่วนของโปรแกรมใหญ่เกินไป ก็จะทำให้การสร้าง automated test case มีความซับซ้อน และมีความเสี่ยงที่จะเกิดความผิดพลาดที่ตัว Test Case เองก็เป็นได้
ขอบคุณแหล่งข้อมูลจาก : http://www.etda.or.th/