code-testing

コードテストスキル

テストの生成、修正、強化を行うための、信頼できる暗黙のエントリーポイントです。範囲を絞った作業は直接処理し、広範囲または複数段階の依頼には公開されているtest-engineerエージェントを呼び出します。

必ず守る実行契約

最初にパイプラインの担当を確認してください。 アクティブなエージェントがtest-engineer（dotnet-test:test-engineerなど、プラグイン名が付いた名前を含む）の場合、または呼び出し元からそのパイプラインのフェーズを割り当てられている場合は、別の生成エージェントに委任しないでください。割り当てられた作業をそのまま実行します。このガードは、以下に記載する範囲の広い作業に関するすべての委任指示に優先します。このスキルが自動的に読み込まれた場合も同様です。

編集前に作業範囲を分類してください。

• 広範囲（プロジェクトまたはパッケージ全体のテストスイート、あるいは複数の本番ファイル／モジュール）：実装前に、解決済みのステージング不可能な<TESTAGENT_DIR>にresearch.mdとplan.mdを作成し、最終的なテスト品質レビュー後に同じ場所へstatus.mdを作成します。test-engineerが利用可能な場合は、実装前にその名前付きカスタムエージェントを呼び出してください。同じラベルを付けた汎用サブエージェントで置き換えたり、広範囲の依頼をそのまま実装したりしないでください。状態ファイルがない場合、広範囲のワークフローは未完了です。
• 範囲限定（ユーザーが作業対象を明示的に1つの関数／クラス／ファイル、または1つの未実装メソッドに限定している場合）：中間状態ファイルを作成せず、複数のエージェントにも作業を分散しないでください。ソースモジュールが1つしかなくても、プロジェクト全体を対象とする曖昧な依頼は広範囲とします。

どちらの範囲でも、関連する中で最も対象を絞ったテストコマンドを実行し、正常に終了させてください。呼び出し元から規約が指定されている場合も含め、必ず安全に報告できるテスト名と結果の検証を適用してください。この契約を委任先の実装担当者／テスターに伝え、エッジケースのデータを保持し、コンソール出力だけでなく設定済みのレポートも検証してください。 引き継ぎの内容は作業量に応じたものにしてください。範囲限定の要件が1～3件の場合は、テスト名と成功したコマンドを記載した簡潔な箇条書きを要件の網羅状況というラベルの下に記載します。広範囲の作業または複数要件がある場合は、要件 | 根拠の表を使用してください。各要望の動作について、正確なテスト名を挙げてください。

広範囲の作業の最終回答を送る前に、回答自体に| 要件 | 根拠 |と、各動作の行に対応する正確なテスト名が含まれていることを確認してください。子レポートや内部計画に表があっても不十分です。テスト名をモジュール単位の箇条書きや領域 | テストの表にまとめて省略しないでください。

中間状態ファイルは内部作業データであり、納品物ではありません。<TESTAGENT_DIR>はステージング不可能な状態に保ち、これやそのファイルをバージョン管理対象のワークスペース内に置かないでください。これらを隠すために.gitignoreを変更しないでください。

網羅性はテスト件数ではなく、要件のマトリックスとして扱ってください。独立した要望である状態、境界、エラーパス、相互作用のそれぞれに、具体的なアサーションを設けてください。1回の実行で要求された組み合わせ全体を実証できる場合に限り、ケースをまとめてください。パラメーター化された正常系のケースを、空の状態、無効な識別子、境界値の直前／一致／直後の代わりにしないでください。 複数の本番モジュールまたはレイヤーを指定する広範囲の依頼では、指定された各モジュールの重要な公開動作を、それぞれ直接テストしてください。モジュール横断テストは組み合わせを実証しますが、要求されたモジュール単位の網羅性の代わりにはなりません。作業の広さは、テスト件数との一致や超過ではなく、動作のマトリックスに基づいて判断してください。

公開エントリーポイントでは、広範囲の作業をtest-engineerに一度だけ委任してください。調査、計画、実装、レビューは引き続き必須ですが、それぞれを別個のサブエージェント呼び出しにする必要はありません。 現在のランタイムで利用できる機能のみを使用してください。利用できないスキルを別名で再試行したり、ポリシーによって拒否された操作を別のエージェントに再試行させたりしないでください。 言語ガイダンスは、呼び出し元から提供された、またはランタイムに一覧表示された code-testing-extensions カタログと、それに対応する言語ファイルから直接読み取ってください。これは参照専用であり、呼び出し可能なスキルではありません。バンドルがない場合は、マニフェストと代表的なテストを使用し、参照情報が見つからないことを報告してください。インストール先のディレクトリを探してはなりません。 スクラッチストレージへのアクセスが拒否された場合は、調査内容と計画をコンテキスト内に保持し、許可されたテストの編集を続け、状態を記録した成果物がないことを報告してください。実行が拒否された場合は、許可された静的レビューを続け、テストを実行できなかったと報告してください。合格したと報告してはなりません。 どちらの阻害要因も、本番コードの変更や要件の緩和を正当化するものではありません。

広範または包括的な依頼では、明示されたマトリックスは最低基準であり、上限ではありません。依頼された各モジュールやレイヤーを単一の動作としてではなく、範囲内の公開操作と、それぞれに固有の検証パス、分岐、境界、相互作用、状態遷移を洗い出すための見出しとして扱ってください。 明示されたマトリックスを満たしたら、各対象 API を調べ、プロンプトで指定されていない、観察可能な同値分割や不変条件を確認してください。具体的には、識別用、空、単一要素、代表的な中間入力、正確な境界値とその直近の値、無効な入力の分割、さらに実装から導かれる順序、単調性、桁あふれ、容量、切り詰め、状態の不変条件を含めます。 まだ検証されていないそれぞれ異なる分割について、変更によって検出できるケースを1つ追加してください。同じ動作を検証する兄弟ケースに限り、パラメーター化またはテーブル駆動のケースを使用してください。カバレッジしきい値に達しても、それは検証であって、網羅性を止める条件ではありません。残りの入力が、明示されたチェックリストを完了したかどうかではなく、同じ分岐と不変条件を検証している場合に終了してください。数を増やすことだけを目的にケースを追加してはなりません。

このスキルを使用する場面

次の作業を行う場合に、このスキルを使用します。

• プロジェクト全体または特定のファイルのユニットテストを生成する
• 既存のコードベースのテストカバレッジを改善する
• プロジェクトの規約に従ったテストファイルを作成する
• 実際にコンパイルして合格するテストを作成する
• 新機能や、まだテストされていないコードのテストを追加する
• MSTest スイートを生成または拡張する。このエントリースキルで対象範囲とプロジェクトの規約を確認した後、補助的なガイダンスとして writing-mstest-tests を読み込む

使用しない場面

• 既存のテストを実行する場合（run-tests スキルを使用してください）
• テストフレームワーク間を移行する場合（移行スキルを使用してください）
• テストの生成を求めていない、MSTest の API／パターンやモダナイズに関する質問に回答する場合（writing-mstest-tests を使用してください）
• コードやテストの変更が求められていない、失敗したテストの分析のみを行う場合

仕組み

このスキルは、複数の専門エージェントを連携させ、調査 → 計画 → 実装のパイプラインを実行します。

パイプラインの概要

┌─────────────────────────────────────────────────────────────┐
│                     TEST GENERATOR                          │
│  Coordinates the full pipeline and manages state            │
└─────────────────────┬───────────────────────────────────────┘
                      │
        ┌─────────────┼─────────────┐
        ▼             ▼             ▼
┌───────────┐  ┌───────────┐  ┌───────────────┐
│ RESEARCHER│  │  PLANNER  │  │  IMPLEMENTER  │
│           │  │           │  │               │
│ Analyzes  │  │ Creates   │  │ Writes tests  │
│ codebase  │→ │ phased    │→ │ per phase     │
│           │  │ plan      │  │               │
└───────────┘  └───────────┘  └───────┬───────┘
                                      │
                    ┌─────────┬───────┼───────────┐
                    ▼         ▼       ▼           ▼
              ┌─────────┐ ┌───────┐ ┌───────┐ ┌───────┐
              │ BUILDER │ │TESTER │ │ FIXER │ │LINTER │
              │         │ │       │ │       │ │       │
              │ Compiles│ │ Runs  │ │ Fixes │ │Formats│
              │ code    │ │ tests │ │ errors│ │ code  │
              └─────────┘ └───────┘ └───────┘ └───────┘

手順

ステップ 1：ユーザーの依頼を把握する

編集を始める前に、意図と範囲の両方を分類します。

• 生成または拡張：以下の生成ワークフローに従います。
• 修復：対象を限定して失敗を再現し、原因がテストか本番環境の動作かを判断し、許可された最小限の修正を行って、該当するコマンドを再実行します。
• 監査してから修正：test-engineer を呼び出し、内部の品質担当者と実装作業を調整できるようにします。

ユーザーが何を、どの範囲で求めているのかを必ず把握してください。 ユーザーがテストのスタイル、カバレッジ目標、規約について強い要件を示していない場合は、unit-test-generation.prompt.md からガイドラインを確認してください。このプロンプトでは、規約の調査、パラメーター化の方針、動作に基づくカバレッジ、言語固有のパターンに関するベストプラクティスを説明しています。

ステップ 2：実行前にリクエストの規模を見極める

スコープに応じて作業の進め方を調整します。1 ファイルだけのリクエストにパイプライン全体を実行しても、ターン数とツール呼び出しが増えるだけで、テストの質は向上しません。

スコープ	内容	実行方法
限定的	1 つの関数、クラス、またはファイル。「X のテストのみ」既存のテストスイートに不足しているケースを追加する	中間状態ファイルとサブエージェントへの分散実行は省略します。要件チェックリストは頭の中に置くか、最終表にまとめます。対象と、規約を確認するための隣接するテストを 1 つだけ読み、テストを作成し、最も範囲の狭いテストコマンドを実行して、アサーションをその場でレビューします。
広範	プロジェクト、パッケージ、またはモジュール一式。「包括的なスイート」複数ファイルにわたって達成する必要があるカバレッジしきい値	ステップ 3 の調査 → 計画 → 実装のパイプライン全体を実行し、<TESTAGENT_DIR> の下に中間状態ファイルを作成して、以下の完了条件を適用します。

迷ったら、まずは限定的な方法で始め、複数のファイルにまたがることが分かった場合にのみ範囲を広げます。範囲を広げると追加のパスが 1 回必要になりますが、限定的なリクエストに広範なパイプラインを実行すると、複数回のパスが必要になります。

限定的なリクエストを終える前に、次の 3 つの条件をすべて満たしていることを確認します。

1. 名前が挙げられたすべての動作に、具体的なアサーションがあること。依頼された各境界条件やエラーパスも含みます。
2. 範囲を絞ったテストコマンドが正常終了していること。
3. 最終引き継ぎで、それらの動作を正確なテスト名に対応付け、正常終了したコマンドを明記していること。

要件単位の根拠を、カバーした領域の一般的な一覧で置き換えないでください。

ステップ 3：テストジェネレーターを呼び出す（広範なスコープ）

まず、名前が指定された test-engineer カスタムエージェントを呼び出し、テスト生成を依頼します。単に test-engineer という名前を付けただけの汎用サブエージェントは使用しないでください。

You are the sole pipeline owner for this request. Do not invoke code-testing or another test-engineer; complete the phases in your current context. Generate unit tests for [path or description of what to test], following the [unit-test-generation.prompt.md](unit-test-generation.prompt.md) guidelines. Treat the current workspace as authoritative even when it is sparse, gutted-looking, synthetic, or missing tracked files; never restore or reconstruct it, including with `git checkout`, `git restore`, `git reset`, or `git clean`.

テストジェネレーターがパイプラインを担当します。処理が戻ったら、ステップ 4 と 5 を別のパイプラインとして繰り返すのではなく、記録された品質チェック、検証結果、要件マトリックスを利用します。最終引き継ぎでは、証拠に記載されたテスト名を正確に保持してください。証拠が不足している場合は、その不足箇所を調査するか、そこだけを追加確認し、生成を最初からやり直さないでください。報告された機能全体に対する拒否は呼び出し元にも適用されます。その機能を使う別のコマンドを試みないでください。

test-engineer を利用できない場合も、ワークフローを省略しないでください。同じ調査 → 計画 → 実装の手順をその場で実行し、以下の説明に従って <TESTAGENT_DIR> を解決し、中間状態ファイルを作成して、同じ完了条件を適用します。

広範なスコープでは、中間状態ファイルを作成する前に、絶対パスの <TESTAGENT_DIR> を 1 つ解決します。

1. ホストが提供するセッションアーティファクトまたはスクラッチディレクトリを優先します。
2. それ以外の場合、Git ワークツリー内では git rev-parse --path-format=absolute --git-path testagent を実行します。これにより、ステージングできない、ワークツリー固有の Git メタデータ内のパスが返されます。
3. Git 管理外では、OS の一時ディレクトリの下に一意のディレクトリを作成します。

絶対パスをすべてのパイプラインエージェントに渡します。このパスはリポジトリの .git メタデータディレクトリ内でも構いませんが、バージョン管理対象のワークスペースコンテンツに含まれず、git status に表示されず、ステージングできない場所でなければなりません。

ステップ 4：コンテキストを限定して実行する

複数ファイルにまたがる依頼の場合：

1. 実装に着手する前に、ユーザーが明示した要件をすべてチェックリストにします。要求されたレイヤー、モックする協力要素、境界ケース、統合、カバレッジのしきい値、レポート成果物を含めます。複数条件の要件はそのまま転記します。各要件は、組み合わせ全体を検証する 1 つのテストに対応させる必要があります。
2. 要求されたモジュールまたはプロジェクトだけを調査し、チェックリストと簡潔な対象一覧を <TESTAGENT_DIR>/research.md に記述します。
3. すべてのソースファイルやテストファイルを読むのではなく、マニフェスト、シンボル参照、決定的な対応付けツールを再利用します。
4. 大規模な複数ファイルの一覧作成に、利用可能な find-untested-sources スキルが役立つ場合は、一度実行し、その対応付け結果と推奨パスを再利用します。それ以外の場合は、対象を限定して一度だけ手動で対応付けます。利用できないスキルを探してはいけません。
5. 各対象ファイルの計画は一度だけ立て、その後はフェーズを順に実装します。チェックリストの各項目を、少なくとも 1 つの具体的なテストに対応付けるか、対応できない理由を説明します。
6. 修正サイクルでは対象を限定してビルドとテストを実行します。ワークスペースレベルの検証は、広範囲にわたる作業の場合、リポジトリの規約でその実行が必要な場合、または変更が他のプロジェクトに影響する可能性がある場合に限り、最後に一度だけ実行します。
7. 成功を報告する前に、生成したテストを再度開き、すべてのチェックリスト項目が具体的なテスト名とアサーションで検証されていることを確認します。カバレッジだけでは、要求されたモックの差し込み箇所、境界条件、状態遷移、プロパティの組み合わせがテストされた証拠にはなりません。
8. リポジトリに参考となるテストがなく、基本拡張機能だけでは不十分な場合に限り、code-testing-extensions の言語別の例を読みます。
9. .NET では、コマンドを選んだりファイルを作成したりする前に、SDK 形式か従来の非 SDK 形式かを判別します。従来形式のプロジェクトでは、packages.config、既存のフレームワーク／モックのバージョン、カスタムのベースフィクスチャを保持し、新しいテストファイルをすべてプロジェクトの明示的な <Compile Include> 項目に追加して、リポジトリの MSBuild／テストランナーコマンドを使用します。テストを生成するためだけにプロジェクトや依存関係の構成を最新化してはいけません。
10. MSTest では、例外アサーションを選ぶ前に固定されているパッケージのバージョンを確認します。MSTest 3.5.x では Assert.ThrowsException<T> を使用します。[ExpectedException]、Assert.Throws<T>、Assert.ThrowsExactly<T> に置き換えてはいけません。

完了条件

すべてのスコープで、以下の3～5を満たす必要があります。1と2は広範なスコープの成果物です。対象を絞った依頼では、同じ推論をその場で行い、中間状態ファイルは作成しません。

以下のすべてを満たすまで、完了を報告しないでください。

1. (広範なスコープ) <TESTAGENT_DIR>/research.md に、限定した対象の一覧、既存のテスト規約、受け入れチェックリストを記録します。
2. (広範なスコープ) <TESTAGENT_DIR>/plan.md で、チェックリストの各項目を計画中のテストまたは明示的な阻害要因に対応づけます。
3. 生成したテストがコンパイルされ、最も対象を絞った適切なテストコマンドで合格し、共通のレポート向け命名規則と結果検証の条件を満たします。
4. 明示されたユーザー要件すべてを、具体的なテストとアサーションで裏づけます。カバレッジがすでに合格していても、モックの差し込み口、境界ケース、状態遷移、プロパティの組み合わせに不足があれば修正します。最終サマリーでは、監査できるよう、チェックリストの各項目について少なくとも1つの生成テスト名を引用します。引用できるテストがない項目については、実装を続けるか、阻害要因として報告してください。足場づくり、スコープ制限、コマンド、カバレッジ成果物など、非動作要件については、テスト名への無理な対応づけをせず、該当するファイル、コマンド、レポートを引用します。 テスト数が少なくても、合格したテストスイートが自動的に弱いとは限りません。テスト数だけではなく、独立して求められた動作すべてが、直接的で重複のない根拠によって網羅されているかで完全性を判断してください。 広範なスコープ／包括的なスコープでは、限定した対象 API で判明した、観測可能な同値クラスと不変条件のすべてに、変更検知に有効なケースが1つずつあることも、プロンプトで明示されていなくても確認します。 複数のモジュールが指定されている場合は、エンドツーエンドの結合テストに加え、各モジュール固有の自明でない公開動作にも、直接的なテスト根拠があることを確認します。
5. 生成したテストを見直し、動作の網羅漏れや弱いアサーションがないか確認します。広範なスコープでは、利用可能な場合は test-gap-analysis と assertion-quality を実行し、その結果と修正内容を <TESTAGENT_DIR>/status.md に記録します。対象を絞ったスコープでは、各生成アサーションをソースに照らして読み直し、その場で同等のレビューを行います。追加のレビュー工程は実行しません。

最終回答には、要件ごとの根拠を記載します。対象を絞った1～3件の要件には、要件の網羅状況という見出しの下に簡潔な箇条書きを使います。より広範なスコープには、要件 | 根拠 の表を使います。動作要件の根拠には、正確な生成テスト名を記載します。非動作要件の根拠には、該当するプロジェクトファイル、検証コマンド、またはカバレッジレポートを記載します。テストした領域の一般的な一覧は、要件ごとの根拠の代わりにはなりません。

根拠の各項目では、ユーザーの意図を正確に保ちます。要件の特定の組み合わせが重要な場合に限り、文言を逐語引用してください。同じ協力クラスを実行するだけのテストでは、それらの相互作用に関する要件を満たしません。クラスごとの要件には、クラスごとに根拠を引用してください。

試行ではなく、成功した実行を根拠にしてください。 最終的な根拠に記載するコマンドは、正常終了している必要があります。最終的に合格したテストサマリーを引用し、しきい値が要求されている場合は、終了コード0で完了した実行のモジュール別カバレッジ表も引用してください。最後のカバレッジ実行が非ゼロで終了した場合は、修正してから再実行してください。失敗または途中で終了した実行から、しきい値をクリアしたと推測してはいけません。

報告する前に、最終的な作業ツリーの変更を調べ、research.md、plan.md、status.md、その他の中間状態ファイルが、コミット対象の変更に含まれていないことを確認してください。

状態管理

広範囲にわたる実行では、中間状態ファイルが、ホストのスクラッチストレージ、Git メタデータ、または OS の一時領域を利用する、ステージングできない <TESTAGENT_DIR> に保存されます。対象を絞ったリクエストでは、これらのファイルは作成されません。

ファイル	用途
<TESTAGENT_DIR>/research.md	コードベースの分析結果
<TESTAGENT_DIR>/plan.md	フェーズ別の実装計画
<TESTAGENT_DIR>/status.md	最終的な品質レビューと修正

エージェントのリファレンス

エージェント	用途
test-engineer	パイプラインを調整します
code-testing-researcher	コードベースを分析します
code-testing-planner	テスト計画を作成します
code-testing-implementer	テストファイルを作成します
code-testing-builder	コードをコンパイルします
code-testing-tester	テストを実行します
code-testing-fixer	エラーを修正します
code-testing-linter	コードをフォーマットします

要件

• プロジェクトにビルド／テストシステムが設定されていること
• テストフレームワークがインストール済み（またはインストール可能）であること
• GitHub Copilot 拡張機能を備えた VS Code

従来型の非 SDK .NET プロジェクトは、既存のビルド／テストツールチェーンを利用できる場合にサポートされます。現在のマシンで利用できない場合でも、エージェントはバージョン互換性のあるテストを追加して登録できますが、dotnet test に置き換えるのではなく、実行がブロックされていることを報告する必要があります。

トラブルシューティング

テストをコンパイルできない

code-testing-fixer エージェントがコンパイルエラーの解決を試みます。想定されるテスト構成については、<TESTAGENT_DIR>/plan.md を確認してください。エラーコードの参照については、指定された code-testing-extensions カタログ内で該当する言語ファイル（例：.NET の場合は dotnet.md）を参照してください。

テストが失敗する

生成されたテストの失敗の多くは、製品コードのバグではなく、アサーションの期待値が誤っていることが原因です。

1. 実際のテスト出力を確認します
2. 製品コードを読み、正しい動作を理解します
3. 製品コードではなく、アサーションを修正します
4. テストを通すためだけに、テストを [Ignore] または [Skip] にしてはいけません

誤ったテストフレームワークが検出される

最初のリクエストで、希望するフレームワークを指定してください。「Jest テストを生成して……」

環境依存のテストが失敗する

外部サービス、ネットワークエンドポイント、特定のポート、または厳密なタイミングに依存するテストは、CI 環境で失敗します。依存関係をモックしたユニットテストに重点を置いてください。

より広範な検証が失敗する

実装中は、対象を絞ったビルドとテストを実行してください。ソリューションまたはワークスペース全体を対象とするコマンドは、広範囲な作業の場合、リポジトリの規約でそのエントリーポイントが定められている場合、または対象を絞った変更がほかのプロジェクトに影響する可能性がある場合にのみ実行してください。対象を絞ったテストのリクエストを、無条件の完全な非インクリメンタルビルドに拡大してはいけません。