Test Coverage สูงๆ มันดีจริงหรือไม่

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

มาดูกันก่อนว่า Test Coverage คืออะไร

จาก Bliki ของ Martin Fowler อธิบายไว้ว่า

• Test Coverage คือ เครื่องมือที่ช่วยให้เราหาส่วนของ code ที่ไม่ถูกทดสอบ
• Test Coverage ไม่ได้บอกว่า code test ที่เขียนมานั้นดีนะ

วิธีการคิด % ของ Test Coverage ก็ง่ายมากๆ 
มันคืออัตราส่วนระหว่างจำนวน Line of code ที่ถูกเรียกจาก Test กับ จำนวน Line of code ทั้งหมด
ดังรูป

ความเข้าใจผิด นำไปสู่การใช้ที่ผิด

แต่มีหลายๆ ทีม มักนำระดับของ Test Coverage ไปใช้เพื่อเป็น KPI ( Killer Performance Improvement !!! )
หรือตัววัดในเรื่องคุณภาพต่างๆ ของระบบ ตัวอย่างเช่น

ระบบงานของเราต้องมีระดับ Test Coverage 90% นะ
ไม่เช่นนั้นเราถือว่างานยังไม่เสร็จ หรือ ไม่สามารถ deploy ขึ้น production ได้
ยิ่งถ้าใครที่ทำ TDD อาจจะบอกด้วยว่า Test Coverage มันต้อง 100% สิ !!

ถ้าทีมหรือองค์กรมีเป้าหมายเพียงเพื่อทำให้ระดับ Test Coverage มันสูงเพียงอย่างเดียวแล้ว
แต่ละคนก็จะสนใจเพียงระดับของ Test Coverage เท่านั้น
มันอาจจะทำให้เกิดปัญหาตามมา ดังนี้

ทุกๆ คนจะพยายามทำให้ระดับของ Test Coverage สูงอยู่เสมอ
ซึ่งในฐานนะของนักพัฒนาบอกได้เลยว่า
มันสามารถทำได้ง่ายมากๆ แต่สิ่งที่ตามมาก็คือ test ที่มีคุณภาพต่ำ
เพราะว่าสนใจแต่ปริมาณเท่านั้น
ตัวอย่างการเขียน test ที่ไร้คุณภาพก็คือ ไม่มีการตรวจสอบผลการทดสอบ
หรือไม่มีส่วนของการ Assertion นั่นเอง ซึ่งเรียกขำๆ ทั้งน้ำตาว่าเป็น Assert Free Testing

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

สิ่งที่ควรเข้าใจก็คือ  Test ที่ดีเป็นอย่างไร

คนที่เขียน Test ด้วยนั้นต้องมีความเป็นมืออาชีพ (Professional)
ไม่ทำการหมกเม็ดหรือทำอะไรที่เป็นการลดคุณภาพของงานที่ทำลงไป
เพราะว่าเรื่องคุณภาพ ไม่สามารถต่อรองได้
งานทุกงาน ต้อง build-in เรื่อคุณภาพเสมอ

ดังนั้น Test ที่เขียนขึ้นมาควรมีโครงสร้างประกอบด้วย 3 ส่วนคือ Arrange-Act-Assert เสมอ ดังรูป

และสิ่งที่นักพัฒนาควรพึงระลึกไว้เสมอในการเขียน test คือ

• F = Fast
• I  = Isolate
• R = Repeatable
• S = Self-verified
• T = Timely

สุดท้ายแล้วนั้น

อย่าลืมว่า Test Coverage นั้นช่วยทำให้เราเห็นว่า code ส่วนไหนบ้างที่ยังไม่ถูกทดสอบ
จะเป็นสิ่งที่ดีมากๆ ถ้าคุณมีเครื่องมือช่วยตรวจสอบ และ run มันอยู่เสมอๆ

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

สิ่งที่ดี ถ้าเรานำไปใช้ในทางที่ผิด มันก็แย่ได้เช่นกัน …

แล้วคุณล่ะ คิดอย่างไร กับระดับของ Test Coverage