Quantcast
Channel: cc :: somkiat
Viewing all articles
Browse latest Browse all 1997

ว่าด้วยเรื่องของ Test-Driven Bugfixing (TDB)

$
0
0

อ่านไปเจอเรื่อง Test-Driven Bugfixing (TDB) จากหนังสือ Test Driven Development for Embedded C เป็นแนวทางที่น่าสนใจ สำหรับการเขียนชุดการทดสอบแบบอัตโนมัติขึ้นมา นักพัฒนาน่าจะลองนำไปใช้กันดูนะ ปล. ผมชอบเรียกว่า Bug-Driven Development

ในหนังสืออธิบายว่า

เมื่อเกิด bug ขึ้นมา แน่นอนว่าต้องแก้ไขให้ถูกต้อง หลังจากนั้นทำการทดสอบเพื่อทำให้แน่ใจ มั่นใจว่ามันทำงานได้อย่างถูกต้องจริง
อีกอย่างหนึ่งคือ bug มันกำลังบอกหรือสะท้อนให้เห็นว่า การพัฒนาและทดสอบมันแย่ขนาดไหน
ดังนั้นน่าจะเริ่มกลับมาพิจารณา เพื่อหาแนวทางในการแก้ไขและปรับปรุงได้แล้วนะ

ดังนั้นเมื่อพบเจอ bug แล้วสิ่งที่ควรทำคือ

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

ต่อมา ถ้าชุดการทดสอบที่เขียนขึ้นมาเพื่อแสดงให้เกิด bug มันทำงานช้า

สิ่งที่ควรต้องทำคือ แก้ไข bug ก่อน เมื่อผ่านแล้ว ให้ทำการแก้ไข test และ code เพื่อให้ทำการทดสอบได้รวดเร็วขึ้น แน่นอนว่า มันก็คือหนังชีวิตเช่นกัน

แต่ถ้าคุณไม่ทำ

ลองคิดเอาเองว่า ค่าใช้จ่ายในการแก้ไข bug แบบนี้ กับแบบที่คุณทำอยู่นั้น แบบไหนมันเปลืองกว่ากัน ทั้งเวลาการหา ทั้งเวลาการแก้ไข ทั้งเวลาการทดสอบ ทั้งเวลาการ deploy ทั้งสิ่งที่ business เสียหายไป
วันนี้คุณแก้ไข bug ด้วยวการแก้ไขที่ต้นเหตุจริง ๆ หรือยัง ? หรือแค่ทำการ patch หรือ workaround หรือพูดตรง ๆ คือ แก้ให้ผ่าน ๆ ไปก่อน เท่านั้นเอง
 

Viewing all articles
Browse latest Browse all 1997

Trending Articles