dotnet-testの多言語単体テスト生成エージェントを導入する方法｜Copilot CLI・VS Code対応状況

「GitHub Copilotに単体テストを作らせても、既存プロジェクトの命名規則に合わない」「テスト単体では成功するのに、CIでは検出されない」といった問題は珍しくありません。

Microsoftが2026年7月31日に公開したdotnet-testプラグインのcode-testing-generatorは、対象コードだけでなく、リポジトリ内のテスト構成、使用言語、テストフレームワーク、実行コマンドまで調査したうえで単体テストを生成するエージェントです。名称に「dotnet」と付いていますが、C#だけでなくPython、TypeScript、Java、Go、Rustなどにも対応します。

利用環境は、GitHub Copilot CLIが正式な導入先、Visual Studio CodeとVS Code Insidersはプラグイン対応がPreview、Visual Studioは現時点で未対応です。また、生成対象は単体テストに限定され、統合テスト、E2Eテスト、ブラウザーテスト、性能テストは現在のスコープに含まれません。(Microsoft for Developers)

dotnet-testのcode-testing-generatorとは

code-testing-generatorは、Microsoftの.NETチームが公開しているオープンソースの.NET Agent Skillsに含まれるテスト生成エージェントです。dotnet/skillsリポジトリ内のdotnet-testプラグインとして提供されています。

一般的なコード生成では、ユーザーが「単体テストを生成して」と依頼すると、AIがすぐにテストコードを書き始めることがあります。しかし、実際の開発では次の情報を確認しなければ、リポジトリに適合したテストにはなりません。

• テスト対象のコードはどこにあるか
• 既存テストはどのプロジェクトやディレクトリに置かれているか
• xUnit、MSTest、pytest、Jestなど、どのフレームワークを使用しているか
• テストクラスやメソッドにどの命名規則があるか
• ビルドやテストを実行する正しいコマンドは何か
• CIがどの方法でテストを検出しているか
• 外部サービスやデータベースをどこでモックすべきか

code-testing-generatorは、これらをリポジトリから調査し、計画、実装、ビルド、テスト実行、修正、品質確認までを一連の流れとして処理します。単に「コンパイルできるテスト」を作るのではなく、リポジトリの通常のテストコマンドから新しいテストが検出されるかまで確認する点が特徴です。(Microsoft for Developers)

dotnet-testのcode-testing-generatorを導入できるホストと対象テストは？

対応状況を先に整理すると、次のようになります。

ホスト	対応状況	導入方法	現時点での判断
GitHub Copilot CLI	対応済み	プラグインマーケットプレイスからインストール	最初に試す環境として適している
Visual Studio Code	Preview	プラグイン機能を有効化してインストール	検証環境での利用向け
VS Code Insiders	Preview	Visual Studio Codeと同様	新機能を先行検証したい場合に向く
Visual Studio	未対応	現在は利用不可	今後の対応を待つ必要がある

MicrosoftはVisual Studioへの対応を進めているとしていますが、公開時期は発表していません。Visual StudioとVisual Studio Codeは名前が似ていますが、対応状況は異なるため注意してください。(Microsoft for Developers)

現在の対象は単体テストのみ

code-testing-generatorが対象とするのは、コードを外部環境から切り離して検証する単体テストです。

テストの種類	対応	具体例
単体テスト	対応	関数、クラス、サービス、モジュールの振る舞いを検証
モックを使った単体テスト	対応	HTTPクライアント、リポジトリ、時刻、ファイル操作などを差し替えて検証
統合テスト	対象外	実データベース、複数サービス、コンテナを組み合わせた検証
E2Eテスト	対象外	システム全体を利用者と同じ経路で検証
ブラウザーテスト	対象外	PlaywrightやSeleniumによる画面操作
性能テスト	対象外	負荷、応答時間、スループットの計測

エージェントは、外部URLへのアクセス、ポートの待ち受け、正確な実行タイミングに依存するテストを避け、外部依存をモックした単体テストを作る方針です。データベースや外部APIを実際に動かす必要がある場合は、別の統合テスト用ワークフローとして扱うのが適切です。(Microsoft for Developers)

「dotnet-test」という名前でも多言語に対応する

dotnet-testはもともと.NET向けのテスト機能を中心に作られたプラグインですが、テスト生成パイプラインと一部の品質分析機能は多言語対応です。

代表的な対応言語とテストフレームワークは次のとおりです。

言語	主な対応フレームワーク
C#／.NET	MSTest、xUnit、NUnit、TUnit
Python	pytest、unittest
TypeScript／JavaScript	Jest、Vitest、Mocha、Jasmine、node:test
Java	JUnit 4／5、TestNG
Go	testing、testify
Ruby	RSpec、Minitest
Rust	標準テスト、proptest
Swift	XCTest、Swift Testing
Kotlin	JUnit、Kotest
PowerShell	Pester
C++	GoogleTest、Catch2、doctest、Boost.Test

ただし、dotnet-testプラグインのすべての機能が多言語対応という意味ではありません。テスト生成やテスト品質分析は多言語に対応しますが、dotnet testの実行支援、CRAPスコア、.NETコードのテスタビリティ改善などは.NET専用です。

非.NETプロジェクトでカバレッジを測定する場合は、pytest-cov、Jestのカバレッジ機能、JaCoCo、go test -coverprofileなど、各言語のツールを利用します。(GitHub)

code-testing-generatorが単体テストを生成する流れ

エージェントは、依頼を受けるとすぐに大量のテストファイルを作るのではなく、対象範囲に応じて処理方法を変えます。

段階	主な処理
調査	対象コード、既存テスト、使用言語、フレームワーク、命名規則、ビルド・テストコマンドを確認
戦略選択	小規模なら直接実装、中規模なら1回の調査・計画・実装、大規模なら反復処理を選択
計画	要求された振る舞いと、作成するテストファイル・テストケースを対応付ける
実装	既存規約に合わせてテストを生成し、ビルドとテストを繰り返す
品質確認	弱いアサーション、抜けている境界値、依頼されたシナリオの未実装を確認
最終検証	ワークスペース全体をビルドし、通常のテストコマンドから新規テストが検出されることを確認

対象範囲に応じて処理を変える

現在のエージェント定義では、依頼規模に応じて主に次の戦略を使い分けます。

Direct

単一の関数、クラス、ファイルなど、小さな範囲に使用します。

既存テストの規約を確認してすぐにテストを作り、狭い範囲のテストコマンドで検証します。小さな依頼に対して不要な調査ファイルや多数のサブエージェントを動かさないため、比較的効率的です。

Single pass

複数ファイルや1つのモジュールなど、中程度の範囲に使用します。

調査、計画、実装を一巡させ、対象範囲のテストをまとめて生成します。

Iterative

ソリューション全体や、特定のカバレッジ目標を達成するような大規模な依頼に使用します。

最初の実装後に未テスト部分を再評価し、対象を絞りながら追加のテスト生成を繰り返します。(GitHub)

広い範囲では調査・計画ファイルが作られることがある

現在のリポジトリでは、広い範囲のテスト生成時に、次のような.testagentディレクトリ内のファイルを使って状態を管理する設計になっています。

ファイル	用途
.testagent/research.md	対象コード、既存規約、テストコマンド、要求事項の整理
.testagent/plan.md	生成するテストと要求事項の対応付け
.testagent/status.md	進捗や品質確認結果の記録

1クラスだけを対象とするような小規模な依頼では、これらのファイルを作らず、必要な確認をエージェント内部で処理する場合があります。(GitHub)

GitHub Copilot CLIにdotnet-testを導入する手順

GitHub Copilot CLIでは、次の手順でdotnet-testプラグインを導入します。

マーケットプレイスを追加する

Copilot CLIを起動し、次のコマンドを入力します。

/plugin marketplace add dotnet/skills

dotnet-testプラグインをインストールする

続けて、次のコマンドを実行します。

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

Copilot CLIを再起動する

プラグインは再起動後に読み込まれます。インストール後は、いったんCopilot CLIを終了して起動し直してください。

利用可能なスキルやエージェントは、次のコマンドで確認できます。

/skills

/agents

Microsoftの公開記事では、再起動後にエージェント一覧からcode-testing-generatorを選び、次のように依頼する手順が案内されています。

Generate unit tests.

プラグインを更新する場合は、次のコマンドを使用できます。

/plugin update dotnet-test@dotnet-agent-skills

(Microsoft for Developers)

code-testing-generatorが一覧に表示されない場合

ここは、実際に導入する際に注意したいポイントです。

Microsoftの2026年7月31日付の記事では、code-testing-generatorをエージェント一覧から選択するよう案内されています。一方、現在のdotnet/skillsリポジトリでは、code-testing-agentがテスト生成の公開エントリーポイントとされ、code-testing-generatorには内部実装エージェントを示すuser-invocable: falseが設定されています。(Microsoft for Developers)

そのため、インストール後にcode-testing-generatorが/agentsへ表示されない場合は、次の順序で確認するのが安全です。

1. Copilot CLIを再起動する
2. /skillsでcode-testing-agentを確認する
3. /agentsで利用可能なエージェントを確認する
4. 通常のチャットで、対象ファイルを明示して単体テスト生成を依頼する
5. それでも動作しない場合は、dotnet/skillsの最新READMEとdotnet-testの定義を確認する

プラグインとエージェントの公開方法は更新される可能性があるため、名称だけで判断せず、/skillsと/agentsの両方を確認してください。

Visual Studio Codeでdotnet-testを使う手順

Visual Studio CodeとVS Code Insidersでは、プラグイン対応がPreviewとして提供されています。安定運用を前提とするより、まず検証用リポジトリや作業ブランチで試すのが適切です。

settings.jsonでプラグインを有効にする

settings.jsonへ次の設定を追加します。

{
  "chat.plugins.enabled": true,
  "chat.plugins.marketplaces": [
    "dotnet/skills"
  ]
}

設定後、Copilot Chatで次のコマンドを入力し、マーケットプレイスからdotnet-testを探します。

/plugins

拡張機能画面で@agentPluginsフィルターを使用して検索する方法も案内されています。(GitHub)

大規模なテスト生成ではサブエージェント設定も確認する

code-testing-generatorは、調査、計画、実装を担当するサブエージェントから、さらにビルド、テスト、修正、Lintを担当するサブエージェントへ処理を委譲する構成です。

Visual Studio Codeでは、サブエージェントから別のサブエージェントを呼び出す機能が初期状態で無効になっています。複数モジュールを対象とする大規模な依頼で、完全な多段委譲を有効にする場合は、次の設定を追加します。

{
  "chat.plugins.enabled": true,
  "chat.plugins.marketplaces": [
    "dotnet/skills"
  ],
  "chat.subagents.allowInvocationsFromSubagents": true
}

この設定が無効でも、ビルド、テスト、修正、Lintは実行されます。ただし、個別のワーカーへ委譲せず、実装エージェントが処理を直接行います。GitHub Copilot CLIには同じ制限はありません。(GitHub)

単体テスト生成で失敗しにくい依頼の書き方

Generate unit tests.だけでも動作するように設計されていますが、実務では対象と完了条件を明示した方が、意図しない変更や確認漏れを減らせます。

依頼には、次の要素を含めると効果的です。

指定する内容	具体例
対象範囲	src/Billing/InvoiceCalculator.csだけを対象にする
テストフレームワーク	既存のxUnitプロジェクトを使用する
検証する振る舞い	通常値、境界値、null、例外、丸め処理
外部依存の扱い	HTTP、時刻、データベースアクセスはモックする
変更範囲	プロダクションコードは変更しない
完了条件	全テスト成功、既存のテストコマンドから検出されること
報告内容	作成ファイル、テスト名、実行コマンド、残課題を報告する

C#プロジェクト向けの依頼例

src/Billing/InvoiceCalculator.cs の単体テストを生成してください。

既存のテストプロジェクト、xUnit、命名規則を再利用してください。
次のケースをそれぞれ独立したテストで検証してください。

- 割引がない場合
- 割引率が0%の場合
- 割引率が100%の場合
- 金額が0の場合
- 負の金額が渡された場合
- 小数点以下の丸めが発生する場合

外部依存がある場合はモックしてください。
統合テストや実データベースを使うテストは作成しないでください。
プロダクションコードは変更しないでください。

最後に、リポジトリで通常使用しているテストコマンドを実行し、
新しいテストが検出され、既存テストを含めて成功することを確認してください。
作成したテスト名と、それぞれが検証する要求を表で報告してください。

Pythonプロジェクト向けの依頼例

services/payment.py の単体テストをpytestで生成してください。

既存のtestsディレクトリ、fixture、命名規則を再利用してください。
正常系、APIエラー、タイムアウト、不正な金額、空のレスポンスを検証してください。
外部APIは実際に呼び出さずモックしてください。

テスト生成後に、リポジトリで通常使用しているpytestコマンドを実行し、
新しいテストが既存のテストスイートから検出されることを確認してください。

このように「テストを何個作るか」だけでなく、どの振る舞いを、どの依存関係から切り離して検証するかを指定することが重要です。

通常のCopilotによるテスト生成と何が違うのか

Microsoftの内部ベンチマークでは、同じモデルと同じプロンプトを使用した場合、専用エージェントは152件中140件、通常のCopilotは152件中120件のタスクを完了しました。完了率はそれぞれ92.1%と78.9%です。

特に「単体テストを生成して」のように詳細が少ない依頼では、専用エージェントが89件中79件、通常のCopilotが89件中59件を完了しています。リポジトリ調査をワークフローに組み込んだ効果が、曖昧な依頼で表れたと考えられます。

一方、より難しいSWE Atlasの44件では、専用エージェントが16件、通常のCopilotが12件の完了にとどまりました。生成エージェントを導入すれば、どのリポジトリでも自動的に正しいテストが完成するという意味ではありません。(Microsoft for Developers)

実務では、次の確認を人が行う必要があります。

• テスト対象の振る舞いを正しく理解しているか
• 誤った期待値を正解として固定していないか
• モックが実装詳細に依存しすぎていないか
• 弱いnullチェックだけで終わっていないか
• 境界値や例外経路が抜けていないか
• プロダクションコードが意図せず変更されていないか
• テストがローカルだけでなくCIからも検出されるか

生成後は必ずgit diffとテスト実行結果を確認し、そのままメインブランチへ反映しないことが重要です。

よくある問題と対処方法

インストールしたエージェントが表示されない

Copilot CLIを再起動し、/skillsと/agentsの両方を確認します。

現在のリポジトリではcode-testing-agentが公開入口、code-testing-generatorが内部エージェントとして定義されているため、ブログ記事と表示名が異なる可能性があります。

意図しないテストフレームワークが使われる

既存テストからフレームワークを自動検出しますが、複数のフレームワークが混在している場合は判断が不安定になることがあります。

次のように明示してください。

既存のMSTestプロジェクトを使用し、xUnitやNUnitのプロジェクトは追加しないでください。

テスト単体では成功するがCIで実行されない

新しいテストプロジェクトがソリューションに追加されていない、CIの対象パターンから外れている、ワークスペース全体のテストコマンドを実行していない可能性があります。

依頼文に次の完了条件を追加します。

個別のテストプロジェクトだけでなく、リポジトリで通常使用している
ワークスペース全体のテストコマンドを実行し、新しいテストが検出されることを確認してください。

外部APIやデータベースへの接続でテストが失敗する

現在の対象は単体テストです。実際のHTTP通信、データベース、ポート、時刻待ちを利用するのではなく、インターフェースやテストダブルで切り離すように指定します。

統合テストも必要な場合は、単体テスト生成とは別の依頼として設計してください。

大きなリポジトリで変更範囲が広がりすぎる

「ソリューション全体の単体テストを作成」と一度に依頼すると、調査対象、実行時間、変更ファイル数が大きくなります。

最初は次の単位で分割するのが安全です。

1. 1クラス
2. 1サービス
3. 1モジュール
4. 関連する複数モジュール
5. ソリューション全体のカバレッジ改善

小さな範囲で生成品質と既存規約への適合を確認してから、対象を広げてください。

dotnet-testを導入すべきケース

dotnet-testの多言語単体テスト生成は、次のような場面に向いています。

向いているケース	理由
既存コードに単体テストを追加したい	リポジトリ内の既存規約を調査してから生成できる
AI生成コードをマージ前に検証したい	実装と単体テスト生成を連続した作業にできる
複数言語を含むリポジトリを管理している	言語ごとのテストフレームワークを検出できる
テストの抜けや弱いアサーションを減らしたい	疑似的なミューテーション確認やアサーション品質確認を行う
CIに認識されるテストを作りたい	リポジトリの通常のテスト実行経路まで確認する
カバレッジ改善対象を段階的に処理したい	規模に応じて直接、単発、反復の戦略を選べる

反対に、ブラウザー操作、実データベース、マイクロサービス間通信、負荷測定を中心とする場合は、現時点のcode-testing-generatorだけで完結させるべきではありません。

まずはCopilot CLIで1クラスから試す

code-testing-generatorは、単体テストコードを書くだけでなく、既存リポジトリを調査し、ビルド、テスト実行、アサーション確認、テスト検出まで行うエージェントです。特に、言語やフレームワークが異なる複数のプロジェクトを管理している場合に活用しやすい機能です。

一方で、Visual Studio Codeのプラグイン対応はPreviewであり、Visual Studioはまだ未対応です。さらに、現在のスコープは単体テストに限定されています。

導入時は、まずGitHub Copilot CLIへdotnet-testをインストールし、作業ブランチ上で1つの関数またはクラスを対象にしてください。生成後にgit diff、テスト名、アサーション、通常のテストコマンドからの検出結果を確認し、問題がなければモジュール単位へ対象を広げるのが安全です。