Code Coverage คือ อะไร และสำคัญยังไง ?

ช่วงนี้พยายามจะดันให้ทุกคนในบริษัทเขียน Test แบบ (Automate) มันมีคำถามว่า แล้วเราจะรู้ได้ยังไง ว่า Test ที่เขียนไปมันมีคุณค่า ไม่ใช่ Test เข้าไป execute ที่ code จุดเดิมซ้ำๆ เลยเป็นที่มาของ Blog นี้ครับ โดยจะมีหัวข้อย่อยๆ ดังนี้

Code Coverage คือ อะไร ?

• Coverage = การครอบคลุม / การคุ้มครอง
• Code Coverage = Code ที่มี Test ครอบคลุม (มี Test คุ้มครอง) เป็นเทคนิคหนึ่งของการทำ White-Box Testing มันช่วยให้เราทราบว่า
  - Test ที่เขียนไป execute ผ่าน code จุดไหนบ้าง
  - จุดไหนที่ Test ยังไม่ครอบคลุม
  - แต่ทว่ามันไม่ได้บอกนะว่า Code นั้นมีคุณภาพที่ดีนะ

• ตัว Code Coverage ปกติจะวัดกัน % (ส่วน Code ที่ Test มัน Execute / จำนวน Code ทั้งหมด) x 100%

เราดู Coverage ยังไง ?

• จริงๆ มี Tools หลายๆตัวเลยนะที่ช่วยแสดงผลได้ง่าย ทั้งตัว SonarQube หรือ reportgenerator.io จากรูปข้างล่างเป็นตัวอย่าง Coverage Report ของตัว Report Generator
  - สีเขียว: Code ที่ Test ผ่าน
  - สีแเดง: Code ที่ Test ยังเข้าไม่ถึง
  - สีเหลือง: Code ที่ Test ผ่านบางส่วน

• ถ้าใครอยากรู้ลึก เรื่อง Coverage มาดูหัวข้อ Code Coverage Type ด้านล่างได้เลยครับ ว่ามันนับจากอะไร จนได้ Report สวยๆ

Code Coverage Type

ก่อนที่เราจะมาจัดกลุ่มจาก Code หยิบยับมากมาย ถ้าใครเรียนสาย SE จะมีการแปลง Code เหล่านั้นออกมาเป็น Graph ซึ่งมีซื่อเรียกว่า Control-Flow Graph เอา Code บรรทัดนั้นๆ มาแปลงเป็น Node ของ Graph ตามตัวอย่างด้านล่าง

หลังจากพอเข้าใจเรื่อง Control-Flow Graph มาดูกันว่าในสาย SE เข้าจัด Coverage กันแบบไหนบ้างครับ

- Statement Coverage (Line Coverage)

• เขียน Test ยังไงก็ได้ ให้ Code บรรทัดนั้นทำงาน

- Branch Coverage

• เขียน Test ยังไงก็ได้ ให้ทุก Branch ถูกทำงาน

- Condition Coverage

• เรียกว่าเป็นการ Zoom เข้าใน Branch Coverage มากกว่า เงื่อนไขของบรรทัดนั้นต้องถูกเรียกใช้ทั้งหมด เช่น

if ((a < b) || (c > 10))
{
  //Execute
}

• จาก Code ข้างต้น ถ้า Test มันเข้าเงื่อนไข a < b แล้ว ถึงว่าได้ Branch Coverage แล้ว แต่จะให้ครบ Condition Coverage ต้องเพิ่ม Test เข้า Case อื่นๆด้วย โดยเขียนตารางสรุปได้ ดังนี้

• หลาย Condition ต้องดูพวก Boundary Case

- Loop Coverage

• ทำให้ครบ Loop ตรงนี้จะมีพวก Boundary Case มาด้วย

- Method Coverage (Function Coverage)

• ถอยออกมาอีกจากเดิมที่เราสนใจ Statement / Branch / Condition / Loop ให้มองในมุมของ Method แทนครับ

- Finite State Machine Coverage

• ถอยออกมาอีก Step เลย ปกติตอนเราออกแบบจะมีเขียนมี (Finite) State Machine Diagram ของ UML อันนี้พยายามเขียน Test ให้เข้าทุก State ครับ ถ้าแต่ละ State นั้นเราแปลงเป็น Method ย่อยๆ แสดงว่า Method เหล่านั้นต้องถูก Test ด้วย

สุดท้าย

Code Coverage เริ่มง่ายๆ

• เขียน Test ขึ้นมาก่อน คิดอะไรที่มัน Automate ได้ก่อน
• Refactor code ถ้ามันเขียน Test ยาก
• ดู Report Coverage ให้เป็น และมาจัดลำดับความสำคัญ เพื่อเพิ่ม Test ให้ Coverage มากที่สุด โดยที่เราเขียนไป มันไม่ซ้ำซ้อนด้วย
• พอได้ Test ที่มี Coverage ระดับนึงช่วยให้มั่นใจใน
  - Quality ของ Product
  - หรือ เวลา Merge Feature ต่างๆเข้ามาได้ หลังๆคนไม่อยาก Merge Code เหตุผลไม่มั่นใจว่าการทำงานเหมือนเดิมไหม หรือ Code หาย
  - และสุดท้ายมันจะสะท้อนไป Cost ของ Regression Test เอง

เมื่อก่อนมี Dev/ QA ที่ค้านผมแนวคิดนี้ผมด้วยนะ เรื่องการทำ Automate Test + ดู Coverage คู่กัน จนย้ายที่ทำงานไป ลองคุยอีกทีแนวคิดเปลี่ยน ตอนนั้นถ้าปรับมา Automate เคส Site xxx นั้นก็คงไม่ยืดยาว ...

Reference

• Application: Control Flow Graphs (toronto.edu)
• Code coverage - Wikipedia