Test coverage คืออะไร?

Question

Accepted Answer

**Test coverage** วัดว่าโค้ดถูก **ดำเนินการโดย test** มากแค่ไหน — โดยทั่วไปเป็นเปอร์เซ็นต์ (เช่น coverage 80%) มันเป็น metric ที่มีประโยชน์สำหรับการค้นหาโค้ดที่ยังไม่ได้ทดสอบ แต่สำคัญที่ต้องเข้าใจข้อจำกัดของมัน: coverage ที่สูงไม่ได้รับประกันว่า test ดี

## coverage วัดอะไร

```text
TEST COVERAGE = the % of code exercised by the test suite:
  LINE coverage → % of code lines executed by tests
  BRANCH coverage → % of branches (if/else paths) taken
  FUNCTION coverage → % of functions called
  STATEMENT coverage → % of statements executed
→ Coverage tools instrument the code and report what tests do/don't exercise.
```

## ทำไม coverage จึงมีประโยชน์

```text
✓ FINDS UNTESTED code — low coverage areas reveal what lacks tests (a gap finder)
✓ A measurable quality signal; track it over time; many teams set a target (e.g. ≥80%)
✓ Highlights branches/paths/error cases that tests miss
```

## ข้อจำกัด (สำคัญ!)

```text
⚠️ HIGH COVERAGE ≠ GOOD TESTS:
  → coverage shows code was EXECUTED, NOT that behavior was correctly VERIFIED
  → you can execute code with NO meaningful assertions → 100% coverage, tests verify nothing
  → 100% coverage can still miss bugs (untested input combinations, logic errors)
⚠️ Chasing a coverage NUMBER → writing low-value tests just to hit the target
→ Coverage is a USEFUL guide (find gaps), NOT a guarantee of quality. Use it wisely;
  focus on testing important behavior well, not just hitting a percentage.
```

## ทำไมจึงสำคัญ

การเข้าใจ test coverage — รวมถึงข้อจำกัดของมัน — มีคุณค่า เพราะมันเป็น **metric ที่ใช้กันบ่อย** ซึ่งมีประโยชน์เมื่อเข้าใจอย่างถูกต้องแต่ทำให้เข้าใจผิดได้เมื่อใช้ผิด จึงเป็นความรู้เชิงปฏิบัติที่สำคัญ

coverage วัด **ว่าโค้ดถูกดำเนินการโดย test มากแค่ไหน** (เป็นเปอร์เซ็นต์ ผ่าน line, branch, function หรือ statement coverage) และการเข้าใจมันมีประโยชน์ เพราะมัน **ค้นหาโค้ดที่ยังไม่ได้ทดสอบ** (เปิดเผยช่องว่างที่ test ยังขาดไป — เป็นวิธีที่มีค่าในการระบุว่าอะไรต้องการการทดสอบ) ให้สัญญาณคุณภาพที่วัดได้ซึ่งทีมสามารถติดตามได้ และเน้นจุดที่ branch และกรณีข้อผิดพลาดถูกพลาดไป

หลายทีมใช้ coverage เป็น metric คุณภาพพร้อมเป้าหมาย

อย่างไรก็ตาม การเข้าใจ **ข้อจำกัดเป็นสิ่งสำคัญอย่างยิ่ง**: **coverage ที่สูงไม่เท่ากับ test ที่ดี** — coverage แสดงว่าโค้ดถูก *ดำเนินการ* ไม่ใช่ว่าพฤติกรรมถูก *ตรวจสอบ* อย่างถูกต้อง ดังนั้นคุณอาจมี coverage ที่สูง (แม้แต่ 100%) ด้วย test ที่ไร้ความหมาย (การดำเนินการโค้ดโดยไม่มี assertion ที่เหมาะสมไม่ได้ตรวจสอบอะไรเลย) และ coverage ที่เต็มก็ยังพลาด bug ได้ (input combination ที่ยังไม่ได้ทดสอบ ข้อผิดพลาดเชิงตรรกะ)

อันตรายของการ **ไล่ตามตัวเลข coverage** (การเขียน test ที่มีคุณค่าต่ำเพียงเพื่อให้ถึงเป้าหมาย) เป็น anti-pattern ที่เกิดขึ้นจริง

การเข้าใจว่า **coverage เป็นแนวทางที่มีประโยชน์สำหรับการค้นหาช่องว่าง ไม่ใช่การรับประกันคุณภาพ** — และว่าควรมุ่งเน้นไปที่การทดสอบพฤติกรรมที่สำคัญให้ดีมากกว่าการไล่ตามเปอร์เซ็นต์ — สะท้อนถึงวิจารณญาณที่เป็นผู้ใหญ่ซึ่งหลีกเลี่ยงข้อผิดพลาดที่พบบ่อยของการมองว่า coverage เป็นเป้าหมายแทนที่จะเป็นเครื่องมือ

เนื่องจาก coverage เป็น metric ที่ใช้กันอย่างแพร่หลายซึ่งมีประโยชน์อย่างแท้จริง (การค้นหาโค้ดที่ยังไม่ได้ทดสอบ) แต่มักถูกเข้าใจผิดและใช้ผิด (มองว่าเป็นการรับประกันคุณภาพหรือเป้าหมายที่ต้องหลอกล่อ) และเนื่องจากการเข้าใจทั้งคุณค่าและข้อจำกัดที่สำคัญของมันช่วยให้ใช้มันได้อย่างชาญฉลาด การเข้าใจ test coverage จึงเป็นความรู้ที่มีคุณค่าและเกี่ยวข้องในทางปฏิบัติ — metric ที่มีประโยชน์ที่ต้องเข้าใจอย่างถูกต้อง ซึ่งการเห็นคุณค่าของข้อจำกัด (coverage ≠ คุณภาพ) สำคัญพอๆ กับตัว metric เอง สะท้อนถึงวิจารณญาณด้านการทดสอบที่ดี