ปัจจัยทำให้ TDD ได้ผลลัพธ์ที่ดี
เรื่องนี้เป็นสรุปแบบย่อ จาก A Dissection of the Test-Driven Development Process: Does It Really Matter to Test-First or to Test-Last? โดยผู้เขียน Davide Fucci และคณะ ในปี 2017
Paper นี้จะใช้กลุ่มทดสอบจากบริษัท A ซึ่งเป็นบริษัท Security Solution ขนาดใหญ่ และบริษัท B ที่เป็น SME ที่ทำ Online Entertainment Platform โดยมาทำ workshop ที่เกี่ยวข้องกับ Unit Test และ TDD จากนั้นก็มีการทำการทดสอบเพื่อดูผลลัพธ์ กับปัจจัยต่างๆ
โดยผลลัพธ์ที่ดูได้แก่ External Quality ซึ่งในกรณีนี้จะดูจาก ค่าเฉลี่ยของความถูกต้องเป็นเปอร์เซ็น ขณะที่ Developer Productivity จะดูจากความเร็วในการทำ production code หรือจำนวน function ที่ deliver ต่อช่วงเวลา
ขณะที่ Factor ที่ดูจะประกอบด้วย
- Granularity — ขนาดของ coding cycle ดูจากค่ามัธยฐานของความยาวของแต่ละ cycle
- Uniformity — เป็น Median Absolute Deviation (MAD) ของความยาวของแต่ละ cycle
- Sequencing — ดูจากสัดส่วนที่ใช้ทำ Test First
- Refactor Effort — วัดโดยใช้สัดส่วนของ Refactor cycle ในกระบวนการ
ผลการทดสอบที่ได้ จะพบว่า
External Quality ที่ดีขึ้นมีความสอดคล้องกับ การทำ Development Cycle ที่สั้นและมีระยะเวลาใกล้เคียงกัน ขณะที่ Refactoring มีผลเชิงลบ และ Sequencing ไม่มีความเกี่ยวข้องกับ External Quality
ขณะที่ ในถ้าของ Developer Productivity นั้น Development Cycle ที่สั้น่และมีระยะเวลาใกล้เคียงกันก็มีผลดีเช่นเดียวกัน ขณะที่ Refactoring ก็ให้ผลดี ส่วน Sequencing ไม่ส่งผลเช่นเดิม
ทางผู้เขียนจึงให้ข้อสรุปว่า
Granularity และ Uniformity เป็นปัจจัยที่สำคัญใน TDD Process ถ้าใครจะทำ TDD ให้มีประสิทธิภาพควรจะ Break down งานที่ต้องทำให้มีขนาดเล็กจะมีขนาดที่ใกล้เคียงกัน โดยคำแนะนำของทางผู้เขียนคือ ให้ทำให้ Task Cycle อยู่ระหว่าง 5–10 นาที
ลำดับของการเขียนเทสไม่ส่งผลต่อ TDD Process มากนัก ตรงนี้น่าจะเป็นความรู้สึกขัดแย้งกับคนที่ทำ TDD Practice แต่ทั้งหมดนี้ต้องบอกก่อนว่า อยู่ในเงื่อนไขที่ มี Granularity ที่เท่าๆกัน ซึ่งในทางปฏิบัตินั้นอาจจะเป็นอีกเรื่อง เพราะ Test-Last มีแนวโน้มที่จะขยาย Granularity จากจินตนาการของคนเขียนโค้ด
สุดท้าย ส่วนตัวคิดว่าประสิทธิภาพของ TDD เกิดจากการที่คนเขียนโค้ดสามารถควบคุมผลลัพธ์ของ Task ที่ทำอยู่ได้อย่างมีประสิทธิภาพ ซึ่งได้มาจาก cycle ที่มีขนาดเล็กจากการกำหนดเนื้องานในแต่ละรอบที่พอดีคำ พอดีกับความสามารถของผู้เขียน
ขณะที่ Test first กับ Test Last แม้ในเอกสารนี้จะบอกว่า ถ้าขนาดของ Cycle เท่ากันแล้ว ก็จะลำดับยังไงไม่มีผลมากนัก แต่ปัญหาที่เจอก็มักจะเป็น เขียนโค้ดเกิน spec สำหรับ test ประจำ ซึ่งก็ทำให้เกิดการหลุดเกิดขึ้น
แต่ถ้าใครยังไม่เคยเขียน Test อะไรเลย ไม่ต้องคิดว่าจะ Test First หรือ Test Last ครับ มี Test สำคัญที่สุด ผมเชื่อในคำหนึ่งของพี่ Roofimon ที่พูดนานมากแล้วว่า “มนุษย์เป็นสิ่งมีชีวิตที่มีอารมณ์อ่อนไหว” คนเดียวกันเขียนโค้ดตอนปกติ กับตอนอกหัก มันจะได้โค้ดไม่เหมือนกัน Test เป็นหลักฐานเชิงประจักษ์อันไร้ซึ่งอารมณ์ ที่จะบอกเราว่า เราทำงานเสร็จแล้วจริงๆนะ
ที่มา
- A Dissection of the Test-Driven Development Process: Does It Really Matter to Test-First or to Test-Last?, Davide Fucci, Hakan Erdogmus, Burak Turhan, Markku Oivo, Natalia Juristo, IEEE Transaction on Software Engineering Volume: 43, Issue: 7, July 1 2017