微軟開源跨語言單元測試代理，內部評測完成率達92.1%，高於原生GitHub Copilot的78.9%。此工具可先辨識程式語言、測試框架與既有測試流程，再自動產生並驗證單元測試，已支援多種語言與CLI、VS Code等環境。
微軟.NET團隊近期開源一套跨語言單元測試代理，名稱為code-testing-generator，其目標是讓 Agent 先理解專案結構、測試工具與既有測試慣例，再產生並驗證單元測試。[1][3]
根據公開資訊，這套代理被放在 GitHub 的 dotnet/skills 倉庫中的 dotnet-test plugin 內，並可透過 GitHub Copilot CLI、Visual Studio Code 與 VS Code Insiders 使用，微軟也表示正在準備 Visual Studio 支援。[2][3]
微軟內部評測顯示，該代理在 152 項任務中完成 140 項，完成率為 92.1%，同條件下使用相同 AI model 與 prompt 的原生 GitHub Copilot 完成率為 78.9%。[2][4]
這次差異並不只反映模型能力，而是反映「專用 Agent」與「通用編碼助手」在工作流程設計上的不同：前者以 repository-aware 的方式逐步檢視專案，再決定如何產生與驗證測試；後者則更偏向一次性生成。[2][4]
從流程來看，這套代理的核心價值不在「寫測試」本身，而在「先理解後生成」。它會先掃描 code repository，找出目標程式、測試框架、測試檔案位置與執行方式，再根據專案現況產生測試程式，並檢查新增測試是否真正納入既有自動化流程。[1][3]
這種設計對 unit test 尤其重要，因為單元測試的目的，是驗證個別功能在特定條件下是否符合預期；若測試只是獨立可跑，卻沒有接入專案的 build 與 test pipeline，實際價值會大幅下降。[1][6]
公開資料顯示，該代理不只會生成測試，還會檢查指定情境的涵蓋情形、assertion 的有效性，以及完整專案的 build 與 test 結果，並透過小幅修改待測程式來驗證測試是否真的能抓出行為變化。[1]
這一點很關鍵，因為許多 AI 生成測試的常見問題不是「不能編譯」，而是「看似通過、實際上沒有測到關鍵邏輯」。透過變更測試對象再觀察測試是否失敗，可以檢驗測試是否具備真正的偵錯能力。[1][3]
微軟的結果也顯示，這類 Agent 的優勢主要出現在需求模糊時。89 項較模糊的任務中，專用代理完成 79 項，完成率 88.8%，原生 Copilot 則完成 59 項，為 66.3%；但在 63 項指示詳細的任務中，兩者都完成 61 項。[4]
這代表當 prompt 已經足夠明確時，通用模型與專用代理的差距會縮小；真正拉開差距的是對 repository 上下文的理解、任務拆解能力，以及把測試落地到現有框架中的能力。[2][4]
另有 15 項要求是針對特定程式碼修改補上測試，專用代理全數完成，原生 Copilot 則沒有完成任何一項，顯示它在「依變更內容補齊 regression test」這類任務上更具結構化優勢。[4]
從支援範圍看，這套代理支援 .NET、Python、TypeScript、JavaScript、Java、Go、Ruby、Rust、Swift、Kotlin、PowerShell 與 C++ 等語言，並會依不同專案的既有做法生成測試。[1][4]
不過，微軟也承認並非所有語言都呈現改善。例如在 10 項 PowerShell 任務中，專用代理完成 7 項，原生 Copilot 完成 8 項，顯示樣本數小、語言特性不同時，結果可能出現波動。[4]
因此，這份評測較適合解讀為「repository-aware agent 在多數情境下更可靠」，而不是宣稱任何語言、任何專案都能穩定超越通用 AI 助手。[4]
對企業開發團隊而言，這類工具的直接價值是縮短補測時間，尤其適合既有專案中大量散落的 legacy code、測試覆蓋不足模組，以及需要快速建立 regression test 的情境。[2][4]
若團隊採用常見 .NET 測試框架，或在多語言倉庫中維持一致的測試慣例，這類 Agent 能先辨識框架與執行方式，再把測試納入實際 CI 流程，降低「有測試但跑不起來」的風險。[1][6][14]
對安全與品質治理來說，影響不只在開發速度，也在於可觀測性與可維護性。當測試能被自動檢查是否接入 build pipeline、是否能在程式改動後失敗，團隊更容易及早發現回歸問題。[1][3]
另一個重要面向是資料與程式碼留置位置。公開資訊指出，這不是 hosted service，而是定義在既有 coding agent 內的 skills，因此可在本地工作流程中運行，程式碼維持在使用者環境內。[2]
這一點對重視 source code 管控的組織特別重要，因為測試生成常會碰觸未公開的商業邏輯、內部命名與架構細節，本地化執行可減少額外外部暴露面。[2][4]
但也必須注意，微軟自己已明確提醒，部分語言的測試樣本不大，測試資料不能直接代表所有專案的真實表現；因此導入時不應把 92.1% 解讀成普遍保證，而應視為一個有參考價值的內部 benchmark。[4]
若企業準備導入這類 unit-test agent，第一步應先確認其產出的測試是否真的納入 CI/CD，而不是只停留在本機或臨時執行層級。[1][3]
第二步，應檢查測試是否覆蓋關鍵分支、例外處理與邊界條件，並透過 mutation 思維驗證測試的有效性；若修改程式行為後測試仍通過，通常代表測試訊號過弱。[1]
第三步，建議在導入前盤點各語言與測試框架的現況，以避免 Agent 只生成內容，卻無法正確掛接現有工具鏈。[1][6][14]
第四步，對 PowerShell 或樣本較少的語言，應先進行小範圍試點，不宜直接以單一 benchmark 結論推廣到整個組織。[4]
第五步，若團隊高度重視 source code 隱私與供應鏈風險，應優先採用可在本地與既有開發環境運行的模式，並檢查其權限、plugin 安裝來源與 repository 存取範圍。[2][3]
5步驟修補清單