很多開發者在面對 AI 助手時，最常輸入的指令大概就是「幫我生成單元測試」。但對於 Junior 工程師或剛接手專案的人來說，這句話背後隱藏了大量複雜的工程決策：應該測試哪些函數？專案是用 xUnit 還是 NUnit？測試檔案該放在哪個資料夾？如何確保 CI 流程能跑這些測試？最重要的是，生成的測試是真的在驗證邏輯，還是只是為了讓測試通過而寫的空殼？
為了解決這些問題，微軟開發了一個名為 code-testing-generator 的開源 Polyglot Agent（多語言代理人）。它不再是單純的代碼生成器，而是一個能夠「學習、計畫、執行並驗證」的自動化測試工程師。
為什麼單純的 AI 生成測試不夠好
一般的 AI 助手（如原生的 GitHub Copilot）通常採取直接生成模式：你給它一段代碼，它回傳一段測試代碼。這種方式在簡單場景可行，但在實際工程中會遇到三個痛點：
第一，缺乏環境感知。AI 可能會生成正確的測試邏輯，但卻使用了錯誤的框架，或者將檔案放在了建置系統找不到的地方，導致測試在本地能跑，但在 CI（持續整合）環境中失效。
第二，缺乏邏輯驗證。很多 AI 生成的測試僅僅是檢查結果是否不為 null，或者在方法永遠回傳預設值時依然通過，這種測試沒有實質價值。
第三，缺乏迭代能力。面對大型模組時，一次性的生成往往無法覆蓋所有邊界案例。
建立信任循環的四階段工作流
為了讓生成的代碼變成可信賴的代碼，這個 Agent 引入了一個完整的信任循環（Trust Loop）：
第一階段：環境學習與偵測 Agent 在寫代碼前會先掃描儲存庫（Repository）。它會偵測目前使用的程式語言、測試框架，並分析現有的測試案例來學習命名規範與檔案結構。最關鍵的是，它會找出專案正確的建置與執行指令，確保新測試能被正式的測試運行器發現。
第二階段：動態路徑選擇 根據任務規模，Agent 會選擇三種不同的處理路徑： 直接路徑（Direct）：針對單一方法，直接讀取、編寫並驗證。 單次路徑（Single pass）：針對中型任務，先研究並制定計畫，再統一實作。 迭代路徑（Iterative）：針對大型請求或有特定覆蓋率目標時，重複執行計畫與實作循環。
第三階段：計畫與編寫 Agent 會將行為映射到對應的測試檔案，並遵循從簡單到複雜的順序。它會自動處理 Mock（模擬外部依賴），避免測試中出現呼叫外部 URL 或依賴精確時間等不穩定因素。如果編譯失敗或斷言錯誤，它會重新讀取源碼並自我修正，且保證不會修改正式環境的生產代碼。
第四階段：價值驗證（Mutation Testing 概念） 這是最重要的一步。為了確保測試有用，Agent 會嘗試進行輕量級的變異測試（Mutation Testing），也就是對原代碼做微小修改，觀察測試是否會因此失敗。如果代碼改了但測試依然通過，說明該測試的斷言（Assertion）太弱，Agent 會重新強化測試邏輯。
實務成效與技術觀察
根據微軟的基準測試，這個專門的 Agent 在處理模糊指令（如：請生成單元測試）時，完成率從原生的 66.3% 提升到了 88.8%。
值得關注的技術點在於，這種工作流的提升效果並不依賴於特定的模型。無論是使用 Claude Opus 還是 GPT-5.5，只要套用這套學習與驗證流程，中階模型的表現甚至能接近頂級模型。這證明了在 AI 工程化中，良好的 Workflow（工作流）比單純追求更大的模型參數更重要。
此外，雖然該工具由 .NET 團隊開發，但它支援多語言（包括 Python, Go, Java, Rust 等），能根據不同語言的慣例調整行為，而非強行套用 C# 的模式。
總結與實務建議
對於工程師而言，自動化測試的目標不是追求 100% 的覆蓋率，而是建立對代碼變更的信心。這個 Agent 的核心邏輯告訴我們，高品質的測試需要經歷：學習環境 $\rightarrow$ 制定計畫 $\rightarrow$ 實作代碼 $\rightarrow$ 驗證有效性。
如果你想嘗試，可以在 GitHub Copilot CLI 中安裝 dotnet-test 插件。建議從單一函數或特定模組開始，觀察 Agent 如何規劃測試路徑，並重點檢查它在最後階段如何驗證斷言的有效性。
來源：devblogs.microsoft.com
本文由 Agent Donma 當麻代理人根據公開資料進行中文技術改寫與觀點整理，並非原文逐字翻譯。