Qodo Cover 已停止維護：高測試覆蓋率為何仍可能抓不到 bug？

โดย Nokka (นก-กา) | ตอนที่ 5 จาก 7 ของชุด "สร้างซอฟต์แวร์ด้วย AI" | ตรวจสอบข้อมูล ณ 23 ต.ค. 2026

บทความนี้เขียนโดย AI (deepseek-v4.1-flash · ผู้ให้บริการโมเดล: ollama-cloud) ผ่าน Hermes Agent ภายใต้การควบคุมและตรวจสอบคุณภาพโดยมนุษย์ - Nokka (นก-กา)

สมมติว่าตัวเลข coverage เพิ่มจาก 62 เปอร์เซ็นต์เป็น 84 เปอร์เซ็นต์ เรื่องแบบนี้ฟังดูเหมือนความสำเร็จ

แต่ถ้าเทสต์ที่เพิ่มเข้ามาไม่มี assertion สักบรรทัด ตัวเลขนั้นก็ไม่ได้บอกอะไรเกี่ยวกับคุณภาพของโค้ดเลย

บทนี้ผมจะเล่าเรื่องเครื่องมือที่เคยถูกแนะนำว่าเป็นคำตอบของปัญหานี้ว่าตอนนี้เป็นอย่างไร แล้วชี้ว่ากับดักที่แท้จริงอยู่ตรงไหน

Qodo Cover คืออะไร และทำไมมันหยุดพัฒนา

Qodo Cover หรือชื่อเดิม Codium Cover Agent เป็นเครื่องมือที่ทำงานต่างจาก agent ตัวอื่นในซีรี่ส์นี้

มันไม่ได้เขียนฟีเจอร์ แต่รับโค้ดที่มีอยู่แล้ว ดูว่า coverage ส่วนไหนยังขาด แล้วเขียนเทสต์เพิ่มให้

ตัวเลข ณ วันที่ผมตรวจคือ 5,670 ดาว สัญญาอนุญาต AGPL-3.0 commit ล่าสุด 24 มิ.ย. 2025 และมีการ push ครั้งหลังสุด 5 เม.ย. 2026 [1]

แต่จุดที่สำคัญกว่าตัวเลขคือบรรทัดใน README ที่เขียนไว้เมื่อ 15 มิ.ย. 2025 ว่า repo นี้ไม่ได้รับการดูแลต่อแล้ว และแนะนำให้ fork ไปทำต่อเองถ้าต้องการ [1]

แปลว่าโค้ดไม่ถูกแตะมากว่าสิบหกเดือน รีลีสสุดท้ายคือ 0.3.10 เมื่อ 21 พ.ค. 2025 [5] และไม่มีใครรับประกันว่ามันจะยังทำงานกับ API ของโมเดลรุ่นใหม่ได้

ในมุมมองของผม การที่มันยังมีดาวเยอะและยังถูกพูดถึง เป็นตัวอย่างที่ดีของปัญหาในวงการนี้ คือข้อมูลเก่าไหลเวียนนานกว่าอายุของเครื่องมือ

สิ่งที่มันต้องการก่อนเริ่มทำงาน

README ระบุเงื่อนไขสองข้อที่คนอ่านข้ามบ่อย [1]

ข้อแรกคือต้องมีคีย์ของโมเดล ตัวแปรที่มันอ่านคือ OPENAI_API_KEY

ข้อสองคือต้องมีไฟล์ coverage รูปแบบ Cobertura XML อยู่แล้ว

ข้อสองนี้สำคัญมาก เพราะมันหมายความว่าเครื่องมือนี้ไม่สามารถเริ่มจากศูนย์ได้ คุณต้องมี test runner ที่ออกรายงาน XML ได้ก่อน

ถ้าโปรเจกต์ของคุณยังไม่มีอะไรแบบนั้น Qodo Cover จะไม่มีข้อมูลว่าโค้ดส่วนไหนยังไม่ถูกทดสอบ

หน้าตาของคำสั่งที่ต้องรัน

ผมเขียนตัวอย่างสมมติด้านล่างเพื่อให้เห็นลำดับงาน ไม่ได้คัดลอกจาก repo ตรง ๆ

1. รัน pytest --cov --cov-report=xml  ->  ได้ coverage.xml
2. ตั้งค่า OPENAI_API_KEY ใน environment
3. เรียก cover-agent ผ่าน CLI พร้อมระบุ path ของ coverage.xml
4. ตรวจ diff ของเทสต์ที่มันเขียน แล้วตัดสินใจว่าจะรับหรือไม่

ขั้นที่ 4 คือขั้นที่คนมักข้าม และเป็นขั้นที่ทำให้ coverage สูงขึ้นโดยที่คุณภาพไม่ขยับ

กับดักที่แท้จริงไม่ใช่ตัวเครื่องมือ

สมมติว่าคุณมีฟังก์ชันหาราคาสินค้าที่มีส่วนลดหลายชั้น และ agent เขียนเทสต์ให้ออกมาแบบนี้ (ตัวอย่างสมมติที่ผมแต่งขึ้น)

def test_calculate_price():
    result = calculate_price(100, 10)
    assert result is not None

เทสต์นี้ทำให้บรรทัดในฟังก์ชันถูกเรียกครบ และ coverage เพิ่มขึ้นจริง

แต่ถ้าฟังก์ชันคืนค่า 9999 มา มันก็ยังผ่าน เพราะสิ่งที่ตรวจมีแค่ว่าไม่ใช่ค่าว่าง

นี่คือความหมายของคำว่า coverage วัดว่าโค้ดถูกเรียกหรือไม่ ไม่ได้วัดว่าโค้ดให้คำตอบถูกหรือไม่

เครื่องมือที่ optimize ตัวเลข coverage จึงมีแรงจูงใจให้เขียนเทสต์ที่เรียกโค้ดให้ครบ มากกว่าเขียนเทสต์ที่จับบั๊กได้

ผมคิดว่า นี่เป็นเหตุผลที่ทีมจำนวนหนึ่งเลิกใช้เครื่องมือประเภทนี้หลังสองสามเดือน แม้ตัวเลขจะสวยขึ้นเรื่อย ๆ

ทางเลือกที่ยังมีคนดูแลอยู่

ถ้าเป้าหมายคือเทสต์ที่จับบั๊กได้จริง วิธีวัดที่ตรงกว่าคือ mutation testing

แนวคิดคือให้เครื่องมือแก้โค้ดของคุณทีละจุด เช่น เปลี่ยนเครื่องหมายบวกเป็นลบ แล้วดูว่าเทสต์จับได้ไหม

ถ้าเทสต์ยังผ่านทั้งที่โค้ดถูกทำให้ผิด แปลว่าเทสต์ชุดนั้นอ่อน

เครื่องมือที่ผมตรวจสถานะแล้วว่ายังเดินอยู่มีสองตัว

mutmut สำหรับ Python · BSD-3-Clause · 1,501 ดาว · commit 19 ต.ค. 2026 [2]
Stryker สำหรับ JavaScript และ TypeScript · Apache-2.0 · 3,269 ดาว · commit 10 ต.ค. 2026 [3]

ทั้งสองตัวไม่ได้เขียนเทสต์ให้คุณ แต่บอกว่าคุณภาพเทสต์ที่คุณมีอยู่ในระดับไหน

ส่วนคนที่ยังอยากได้พฤติกรรมเดิม คือให้ AI เขียนเทสต์เพิ่ม มีทางที่ Qodo เองลิงก์ไว้ คือ GitHub Action ชื่อ qodo-cover [4]

สถานะของมันคือยังอยู่ในช่วง preview ไม่มีไฟล์สัญญาอนุญาตในรีโป และ commit ล่าสุด 13 มี.ค. 2025 [4]

ตัวเลข 27 ดาวน้อยมากเมื่อเทียบกับตัวหลัก ผมจึงอ่านว่า ที่นี่ไม่ใช่ทางที่คนใช้งานจริงเลือก

วิธีออกแบบไปป์ไลน์ที่ไม่หลงตัวเลข

สิ่งที่ผมจะทำถ้าต้องตั้งระบบนี้จริง มีสามชั้น

ชั้นแรก รันเทสต์เดิมและบังคับ coverage ขั้นต่ำใน CI เพื่อกันไม่ให้แย่ลง

ชั้นที่สอง รัน mutation testing แบบจำกัดขอบเขต เฉพาะไฟล์ที่ถูกแก้ใน pull request เพื่อไม่ให้กินเวลาเกิน

ชั้นที่สาม ให้ agent ช่วยเขียนเทสต์ แต่ต้องผ่านการตรวจสองอย่าง คือ mutation score ต้องดีขึ้น และต้องมีคนอ่าน diff

ชั้นที่สามนี้คือจุดที่ Qodo Cover เคยช่วยได้ แต่ตอนนี้ผมต้องบอกตรง ๆ ว่ามันไม่มีคนดูแลแล้ว

ถ้าคุณยังต้องการความสามารถนี้ ทางที่เป็นไปได้คือ fork ไปดูแลเอง หรือใช้ความสามารถเขียนเทสต์ของ agent ที่ยังมีคนดูแลอยู่ แล้วกำหนดเงื่อนไขตรวจรับเอง

สิ่งที่ผมไม่ได้ทดลอง

ผมไม่ได้รัน Qodo Cover ในเครื่องนี้ เพราะต้องมีคีย์ OpenAI และเครื่องที่ผมใช้มีเพียงคีย์ของผู้ให้บริการผ่านทาง OpenRouter

ผมจึงไม่เขียนว่ามันเขียนเทสต์เก่งแค่ไหน และไม่ยกตัวอย่างผลลัพธ์ที่ผมไม่ได้เห็นด้วยตา

ที่ผมยืนยันได้คือสถานะของ repo ถ้อยใน README ตัวเลขจาก GitHub API และเงื่อนไขการใช้งานที่ README ระบุ

เช็กลิสต์ก่อนเลือกเครื่องมือเขียนเทสต์

โปรเจกต์ออกรายงาน coverage แบบ XML ได้แล้วหรือยัง
coverage ขั้นต่ำที่คุณตั้งไว้ วัดจากอะไร
มีเทสต์ที่ assertion ชัดเจนกี่เปอร์เซ็นต์
เครื่องมือที่คุณจะใช้ commit ล่าสุดเมื่อไร
ถ้ามันหยุดพัฒนา พอร์ตไปตัวอื่นใช้เวลากี่วัน

ข้อ 5 ทำให้ผมเลี่ยงเครื่องมือที่ผูกกับรูปแบบไฟล์เฉพาะตัวมากเกินไป เพราะวันหนึ่งคุณต้องย้ายออก

บทเรียนที่ผมอยากฝากไว้

Coverage เป็นตัวเลขที่วัดความพยายามได้ดี แต่วัดคุณภาพได้ไม่ดี

ความมั่นใจว่าเทสต์จะจับบั๊กได้ ต้องมาจากตัววัดที่จับบั๊กเป็น ไม่ใช่ตัววัดว่าโค้ดถูกเรียกหรือยัง

ถ้าคุณกำลังตั้งไปป์ไลน์เทสต์อยู่ เล่าให้ผมฟังได้ว่าทีมตั้ง coverage ขั้นต่ำไว้เท่าไร และเคยลอง mutation testing หรือยัง

บทถัดไปผมจะประกอบทุกชิ้นเข้าด้วยกัน เป็นไปป์ไลน์ตั้งแต่ requirement ไปจนถึง pull request ที่มีด่านตรวจ

[1] GitHub, "qodo-ai/qodo-cover" repository และ README, สืบค้น 23 ต.ค. 2026 (AGPL-3.0 · 5,670 ดาว · commit 24 มิ.ย. 2025 · push 5 เม.ย. 2026 · ประกาศ 15 มิ.ย. 2025 ว่าไม่ได้รับการดูแลต่อ · ระบุเงื่อนไข OPENAI_API_KEY และไฟล์ coverage รูปแบบ Cobertura XML). https://github.com/qodo-ai/qodo-cover

[2] GitHub, "boxed/mutmut" README, สืบค้น 23 ต.ค. 2026 (BSD-3-Clause · 1,501 ดาว · commit 19 ต.ค. 2026 · เครื่องมือ mutation testing สำหรับ Python). https://github.com/boxed/mutmut

[3] GitHub, "stryker-mutator/stryker-js" README, สืบค้น 23 ต.ค. 2026 (Apache-2.0 · 3,269 ดาว · commit 10 ต.ค. 2026 · เครื่องมือ mutation testing สำหรับ JavaScript และ TypeScript). https://github.com/stryker-mutator/stryker-js

[4] GitHub, "qodo-ai/qodo-ci" README, สืบค้น 23 ต.ค. 2026 (GitHub Action สำหรับ Qodo Cover · สถานะ preview · 27 ดาว · commit 13 มี.ค. 2025 · ไม่พบไฟล์สัญญาอนุญาตในรีโป). https://github.com/qodo-ai/qodo-ci

[5] GitHub, "qodo-ai/qodo-cover" releases, สืบค้น 23 ต.ค. 2026 (รีลีสล่าสุด 0.3.10 เมื่อ 21 พ.ค. 2025 ไม่มีรีลีสใหม่หลังประกาศหยุดดูแล). https://github.com/qodo-ai/qodo-cover/releases