Microsoft เปิดซอร์ส code-testing-generator เอเจนต์เขียนยูนิตเทสต์ 12 ภาษา — เบนช์มาร์กภายในทำได้ 92.1% เทียบ Copilot เปล่า 78.9%

วันที่ 31 กรกฎาคม 2026 Amaury Levé (Principal Software Engineer) เขียนบนบล็อก .NET ของ Microsoft แนะนำ code-testing-generator — เอเจนต์เขียนยูนิตเทสต์แบบโอเพนซอร์สที่อยู่ในปลั๊กอิน dotnet-test ของรีโป dotnet/skills ติดตั้งผ่าน plugin marketplace ได้ใน GitHub Copilot CLI, VS Code และ VS Code Insiders (ส่วน Visual Studio ยังทำอยู่)

โจทย์ที่บทความตั้งไว้ตรงกับความหงุดหงิดที่นักพัฒนาทุกคนเคยเจอ: คำสั่งสั้น ๆ ว่า “Generate unit tests” ทิ้งคำถามสำคัญไว้เต็มไปหมด — โค้ดไหนต้องมีเทสต์? โปรเจกต์นี้ใช้เฟรมเวิร์กอะไร? ไฟล์เทสต์ควรอยู่ตรงไหน? แล้ว build จะหาเจอไหม? แนวคิดของปลั๊กอินคือ ให้เอเจนต์ไปหาคำตอบเหล่านั้นจากรีโปเอง แทนที่จะให้นักพัฒนาต้องพิมพ์ลงไปใน prompt

เอเจนต์ทำอะไรก่อนจะเริ่มพิมพ์เทสต์

เวิร์กโฟลว์แบ่งเป็นสี่ช่วง และช่วงที่น่าสนใจที่สุดคือช่วงแรกกับช่วงสุดท้าย

หนึ่ง — เรียนรู้จากรีโปก่อน เอเจนต์ค้นหาโค้ดที่ต้องเทสต์ ตรวจภาษาและเทสต์เฟรมเวิร์ก ดูเทสต์เดิมเพื่อจับรูปแบบและตำแหน่งไฟล์ แล้วหาคำสั่ง build/test ที่ถูกต้อง จุดนี้บทความชี้ปัญหาที่พบบ่อยมากไว้ตรง ๆ: โปรเจกต์เทสต์ใหม่ที่ build ผ่านและ pass ในเครื่องตัวเอง แต่ไม่เคยถูกรันใน CI เลย เพราะไม่ได้ถูกเพิ่มเข้า solution หรือคำสั่งเทสต์ของรีโป เอเจนต์จึงตรวจด้วยว่ารีโปค้นหาเทสต์อย่างไร และยืนยันว่าเทสต์ใหม่โผล่ในนั้นจริง

สอง — เลือกขนาดงานให้พอดี มีสามเส้นทาง: Direct (อ่านโค้ด เขียน ตรวจ), Single pass (วางแผนครั้งเดียวแล้วลงมือ), Iterative (วนซ้ำสำหรับงานใหญ่หรือเป้าหมาย coverage)

สาม — วางแผนและเขียน ไล่จากโค้ดที่ง่ายไปหาโค้ดที่มี dependency เยอะ แมปแต่ละพฤติกรรมไปยังไฟล์เทสต์ ตามคอนเวนชันของรีโป และมีกฎที่ควรชม: ไม่แก้โค้ด production ระหว่างสร้างเทสต์ และเลี่ยงยูนิตเทสต์ที่เรียก URL ภายนอก เปิดพอร์ต หรือขึ้นกับจังหวะเวลาที่แน่นอน

สี่ — ตรวจว่าเทสต์มีประโยชน์จริง ช่วงนี้คือส่วนที่แยกปลั๊กอินนี้ออกจาก “สั่งให้เขียนเทสต์” ธรรมดา เพราะเทสต์ที่ pass อาจไร้ค่าได้ — เช็คแค่ว่าผลลัพธ์ไม่เป็น null, เทสต์ผิดเมธอด, หรือ pass แม้เมธอดจะคืนค่า default เสมอ เอเจนต์จึงลอง แก้โค้ดเล็ก ๆ ที่ควรทำให้เทสต์พัง (mutation testing แบบเบา ๆ), มองหา assertion ที่อ่อนหรือขาด, ตรวจว่าทุกสถานการณ์ที่ขอมีเทสต์รองรับ, build ทั้ง workspace แล้วรันชุดเทสต์ทั้งหมด

ตัวเลขจากเบนช์มาร์ก — และตัวเลขไหนที่บอกอะไรจริง

เบนช์มาร์กภายในของทีมมี 152 งานจากรีโปจริง ผลรวมคือ

ตัวชี้วัด	เอเจนต์เฉพาะทาง	Copilot เปล่า
งานที่ทำสำเร็จ	140/152 (92.1%)	120/152 (78.9%)
เทสต์ที่สร้าง	6,963	7,129
line coverage เฉลี่ย	72.4%	72.2%
branch coverage เฉลี่ย	49.8%	49.1%
เวลาเฉลี่ยต่องาน	359 วินาที	380 วินาที

สังเกตให้ดีว่า coverage แทบเท่ากัน และเอเจนต์สร้างเทสต์น้อยกว่า 2.3% ด้วยซ้ำ ส่วนต่างทั้งหมดมาจากความน่าเชื่อถือ ไม่ใช่ปริมาณ

และเมื่อแยกตามชนิดของ prompt ภาพจะชัดขึ้นมาก:

• prompt คลุมเครือ (89 งาน): 79 (88.8%) เทียบ 59 (66.3%) — ความล้มเหลวลดลง 67%
• prompt ละเอียด (63 งาน): 61 (96.8%) เท่ากันเป๊ะทั้งสองฝั่ง
• งานที่ชี้ไปยัง diff เฉพาะ (15 งาน): เอเจนต์ผ่าน 15/15, Copilot เปล่าผ่าน 0/15

ข้อสรุปที่อ่านออกมาได้ตรง ๆ คือ ปลั๊กอินนี้ไม่ได้ทำให้โมเดลเขียนเทสต์เก่งขึ้น แต่ทำงานบ้านที่นักพัฒนาไม่ได้ใส่ไว้ใน prompt ให้แทน ซึ่งเป็นเหตุผลว่าทำไมเมื่อ prompt ละเอียดพอ ส่วนต่างจึงหายไปจนหมด

ผลข้ามโมเดลบนงาน .NET 45 งานก็น่าสนใจ: Claude Opus 4.8 ได้ 43/45 เทียบ 35/45, GPT-5.5 ได้ 41/45 เทียบ 36/45, Claude Haiku 4.5 ได้ 34/45 เทียบ 25/45 — และเมื่อดูทั้ง 152 งาน GPT-5.5 ที่ใส่เวิร์กโฟลว์นี้ทำได้ 90.1% ห่างจาก Opus ที่ใส่เวิร์กโฟลว์ไม่ถึงสองจุด และสูงกว่า Opus เปล่ากว่า 11 จุด

ด้านภาษา: Python 13/15 เทียบ 6/15, Go 15/15 เทียบ 10/15 — แต่ PowerShell แพ้ 7/10 เทียบ 8/10 ซึ่งบทความยอมรับตรง ๆ ว่ากลุ่มตัวอย่างเล็กและ “เป็นสัญญาณ ไม่ใช่คำสัญญา”

ที่ควรอ่านคู่กันเสมอคือเบนช์มาร์กที่ยากกว่า — SWE Atlas 44 งาน ซึ่งตรวจว่าเทสต์จับบั๊กที่ฝังไว้ได้จริงไหม: เอเจนต์ทำได้ 16/44 (36.4%) เทียบ 12/44 (27.3%) เทสต์ที่ผ่าน 550 เทียบ 493 และจับบั๊กที่ฝังไว้ได้ 360 เทียบ 316 ตัวเลข 36% นี้ห่างจาก 92% มาก และบทความก็เขียนไว้เองว่า “ยังมีอีกมากที่ต้องปรับปรุง”

ติดตั้ง

/plugin marketplace add dotnet/skills
/plugin install dotnet-test@dotnet-agent-skills

รีสตาร์ต CLI แล้วเลือก code-testing-generator จากรายการเอเจนต์ ขอบเขตปัจจุบันคือ ยูนิตเทสต์เท่านั้น — integration, end-to-end, browser และ performance test ยังไม่รวม

มุมมอง AI Curator

สิ่งที่ผมคิดว่าเป็นข่าวจริงในโพสต์นี้ ไม่ใช่ “Microsoft มีเอเจนต์เขียนเทสต์แล้ว” แต่คือ หลักฐานเชิงตัวเลขว่าเวิร์กโฟลว์ที่เขียนดีให้ผลตอบแทนสูงกว่าการอัปเกรดโมเดล ตัวเลข GPT-5.5 + เวิร์กโฟลว์ (90.1%) สูงกว่า Opus เปล่า (ราว 79%) กว่า 11 จุด เป็นตัวเลขที่ทีมไทยควรจำไว้ให้ขึ้นใจ เพราะงบค่าโมเดลของทีมในภูมิภาคเราตึงกว่าทีมในสหรัฐฯ มาก และคำแนะนำที่ได้จากข้อมูลชุดนี้คือ เอาเวลาไปเขียน skill/แนวทางให้เอเจนต์ ก่อนจะอัปเกรดไปโมเดลแพงสุด — ผลตอบแทนต่อบาทต่างกันคนละเรื่อง

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

แต่ต้องอ่านตัวเลขอย่างระมัดระวังสองข้อ ข้อแรก เบนช์มาร์กหลักเป็นของทีมเอง — 152 งานที่ทีมคัดเอง วัดโดยทีมที่สร้างเครื่องมือ ส่วนเบนช์มาร์กสาธารณะที่ยากกว่าอย่าง SWE Atlas ให้ตัวเลข 36.4% ซึ่งเป็นเลขที่ผมคิดว่าใกล้ความจริงของการใช้งานประจำวันมากกว่า ข้อสอง เกณฑ์ “ผ่าน” ของเบนช์มาร์กหลักคือ build ผ่าน + เทสต์ผ่าน + เพิ่มเทสต์อย่างน้อยหนึ่งตัว + ไม่ลบเทสต์เดิม ซึ่งเป็นเกณฑ์เรื่อง ความเรียบร้อย มากกว่า คุณภาพของเทสต์ และบทความก็ยอมรับเองว่าเมื่อทั้งสองฝั่งทำสำเร็จ Copilot เปล่ากลับได้คะแนน assertion และ coverage สูงกว่านิดหน่อย

มุมสุดท้ายที่ผมว่าถูกมองข้าม: Microsoft เบนช์มาร์กเครื่องมือของตัวเอง ทั้งใน GitHub Copilot และ Claude Code และปล่อยเป็น Agent Skills plugin ที่พกข้ามโฮสต์ได้ นี่คือสัญญาณว่าชั้นที่ผู้ขายเริ่มแข่งกันจริง ๆ กำลังขยับจาก “โมเดลของใครเก่งกว่า” ไปเป็น “skill ของใครพกไปใช้ที่ไหนก็ได้และพิสูจน์ผลได้” สำหรับทีมที่กำลังสร้างมาตรฐานภายในองค์กร นี่คือรูปแบบที่ควรลอก: เขียนเวิร์กโฟลว์เป็นไฟล์ในรีโป วัดผลด้วยเบนช์มาร์กของตัวเอง แล้วให้มันทำงานได้กับเอเจนต์ทุกตัวที่ทีมใช้ ไม่ใช่ผูกกับผู้ขายรายเดียว

แหล่งข่าว

• From generated code to trusted code with a unit-test agent — .NET Blog, 31 ก.ค. 2026
• dotnet/skills — ปลั๊กอิน dotnet-test บน GitHub
• Announcing v2.0 of the official MCP C# SDK — .NET Blog, 28 ก.ค. 2026