scaffold-dotnet-test-project

.NET テストプロジェクトのスキャフォールディングまたは修復

不足しているテストコンテナーを最小限作成するか、不足している配線のみを修復します。 目的は、推奨されるソリューションのレイアウトではなく、リポジトリの実際のビルドエントリーポイントを通じてテストを検出できるようにすることです。

リポジトリオーバーレイ

読み取り専用のファイル検査が許可されている、リポジトリに関するすべてのタスクでは、ほかの調査を行う前に、リポジトリのルートにある .agents/skill-overlays/dotnet-test/scaffold-dotnet-test-project.md を確認してください。編集せずにコードやアドバイスを求める依頼も含まれます。「実行しないでください」という指示は、オーバーレイを読むことを禁止するものではありません。ファイルが存在する場合は、作業に取りかかる前に一度だけ読み、そのリポジトリ固有の命名、レイアウト、フレームワーク、およびポリシーの適用規則に従ってください。適用する前に、フロントマターで core: dotnet-test/scaffold-dotnet-test-project、binding-revision: "1"、および mode: extend が宣言されていることを確認してください。いずれかの値がないか異なる場合は、不一致を報告し、このスキルの汎用ガイダンスを使用して続行してください。ただし、オーバーレイは適用しないでください。明示的なユーザー指示と確認済みのプロジェクト上の制約はオーバーレイより優先されます。オーバーレイは、このスキルの汎用的な既定値や例より優先されます。ファイルが存在していても読み取れない場合、またはリポジトリと矛盾する場合は、その問題を報告し、確認済みのプロジェクト上の制約に従いつつ、オーバーレイを適用せずに汎用ガイダンスで続行してください。ファイルが存在しない場合は、通常どおり続行してください。タスクが特定のリポジトリに関するものでない場合、またはユーザーがすべてのファイル／ツールへのアクセスを明示的に禁止している場合に限り、確認を省略してください。オーバーレイによって、ツールの権限やタスクの範囲を拡大することはできません。

依頼の振り分け

編集する前にリポジトリを調査し、次のいずれか1つだけを選択してください。

リポジトリの状態	対応	禁止事項
適切なテストプロジェクトがない	範囲を限定したプロジェクトを1つ作成し、本番プロジェクトを参照して登録する	ソースプロジェクトごとにプロジェクトを作成する
テストプロジェクトはあるが、必要な ProjectReference がない	その参照のみ追加し、直接実行とエントリーポイント経由の実行を検証する	別のプロジェクトをスキャフォールディングする、またはテストを書き換える
テストプロジェクトを直接実行すると成功するが、.sln、.slnx、または .slnf に含まれていない	CI が使用する正確なエントリーポイントに既存プロジェクトを登録する	プロジェクトを再作成する、またはソリューション形式を切り替える
適切なプロジェクト、参照、および依頼されたエントリーポイントの登録がすでに正しい	ワークスペースを変更せず、テストメソッドが必要な場合は code-testing を使用する	動作しているファイルを正規化または置き換える

既存プロジェクトは、ターゲットフレームワークが本番プロジェクトを参照でき、その目的が依頼されたレイヤーに合致している場合に適切とみなします。別の名前が推奨されていることは、重複プロジェクトを作成する理由になりません。

何もしないことも必須の結果です。 適切なプロジェクト、本番プロジェクトへの参照、および依頼されたエントリーポイントへの登録がすでに存在する場合は、ファイルを一切変更しないでください。スモークテストの追加や削除、プロジェクトの正規化、パッケージの再作成、ベースライン／スナップショットのコピーの編集は行わないでください。既存のパスを報告して終了してください。

ワークフロー

1. リポジトリの契約を確認する

タスクの現在の作業ディレクトリから開始します。スキルコンテキストの Base directory はこれらの指示が置かれている場所であり、ユーザーのリポジトリではありません。親の一時ディレクトリを検索したり、スキルのインストール先を作業領域として扱ったりしないでください。想定されるファイルが見つからない場合は、プロジェクトが存在しないと判断する前に現在のディレクトリを確認してください。

すべての編集と検証コマンドは、ユーザーが指定したリポジトリのパス、または現在のディレクトリから特定したリポジトリのパスを基準に実行してください。似た名前のフィクスチャ、ソリューション、コピーされたツリーが存在する場合、依頼されたツリーの代わりに編集や検証を行わないでください。ソリューション成果物を変更する前にその正確なパスを記録し、変更後はただちに同じ成果物を一覧表示してから、テストプロジェクトが表示されていることを確認して次に進んでください。

以下を判断するために必要な範囲だけを読み取ります。

1. 本番プロジェクトと、依頼されたテストの範囲
2. CI で使用されているコマンド、および .sln、.slnx、.slnf、またはプロジェクトグラフ
3. 適切なテストプロジェクトの有無、その参照先、登録場所
4. 近隣のテストプロジェクトで使われているテストフレームワーク、ランナー、ターゲットフレームワーク、nullable、暗黙的な using の規約
5. パッケージや SDK のバージョンが Directory.Packages.props、Directory.Build.props、global.json、または MSBuild SDK 宣言のどこで管理されているか

テストプロジェクトを単独で実行すると成功する一方で、ソリューションレベルの検出で何も見つからないとユーザーが報告している場合は、それを登録状況を示す証拠として扱います。プロジェクトの作成を検討する前に、エントリーポイントを確認してください。

2. プロジェクトが存在しない場合に限り作成する

依頼された本番プロジェクトのうち、最も範囲の狭いものに対してテストプロジェクトを1つ選びます。次の順に従います。ユーザーが明示したフレームワークの指定、近隣のテストプロジェクト、リポジトリ全体のパッケージと SDK の規約、標準の SDK テンプレートです。

生成されるフレームワークの世代とパッケージ形式がリポジトリの契約に合致する場合に限り、dotnet new テンプレートを使用してください。作成前にテンプレートが利用可能か確認します。特に、一般的な dotnet new xunit は xUnit 2 パッケージを出力することがよくあります。パッケージを一元管理する xunit.v3 のリポジトリでは、リポジトリまたはインストール済みの xUnit v3 テンプレートを使うか、最小限の SDK プロジェクトを直接作成してください。バージョン指定付きの xUnit 2 参照を生成してから xUnit v3 に書き換えることは、決して行わないでください。

その後、次の作業を行います。

1. ターゲットフレームワーク、nullable、暗黙的な using、ランナー、パッケージ形式を合わせます。
2. 依頼されたテストで使用する本番プロジェクトだけを対象に、dotnet add <test-project> reference <production-project> を使用します。
3. UnitTest1.cs などのテンプレートのサンプルファイルを削除し、テンプレートのファイル名を流用するのではなく、振る舞いを示す名前のテストファイルを作成します。
4. 中央パッケージ管理でバージョンが指定される場合は、パッケージのバージョン指定を省略します。

MTP を使用する xUnit v3 プロジェクトでは、実行可能な出力とランナーの選択を維持するか、追加してください（または、解決されたパッケージが提供する同等の設定を使用します）。

<OutputType>Exe</OutputType>
<UseMicrosoftTestingPlatformRunner>true</UseMicrosoftTestingPlatformRunner>

TestingPlatformDotnetTestSupport=true を追加するのは、VSTest コマンドモードから MTP へのブリッジに限ります。global.json の test.runner: Microsoft.Testing.Platform で選択される SDK 10 以降のネイティブ MTP モードでは必要ありません。コマンドモードと実行されるランナーを区別するには、platform-detection を使用してください。SDK のバージョンも OutputType=Exe も、それだけではハーネスの検出を証明しません。

3. プロジェクトが存在する場合、不足しているエッジのみを修復する

• 本番参照の欠落: dotnet add <test-project> reference <production-project> を使用し、結果のプロジェクトを確認して、他のすべての プロジェクト要素とすべてのテストソースファイルを変更しないままにします。前後のプロジェクトを比較し、追加された ProjectReference が唯一の意味的な変更であることを確認します。
• .sln または .slnx の登録欠落: dotnet sln <entry-point> add <test-project> を実行し、その後すぐにその正確なパスに対して dotnet sln <entry-point> list を実行します。プロジェクトが存在しない場合、修復は行われていません。兄弟ソリューションを検証したり、成功を報告したりしないでください。
• .slnf の登録欠落: 必要に応じて既存のプロジェクトをその基になるソリューションに追加し、その同じプロジェクトパスをフィルターに含めます。基になるソリューションに既に含まれている場合は、フィルターのみを編集します。
• 複数のソリューション成果物: ユーザーが指定したもの、または CI が呼び出したもののみを変更します。より簡単な形式で代用しないでください。
• ソリューション成果物がない場合: 既存のプロジェクト指向のワークフローを維持します。見た目のためにソリューションを作成しないでください。

4. 要求されたスモーク動作のみを追加する

新しく作成されたプロジェクトの場合、テンプレートの例をユーザーが要求した最小のスモークスイートに置き換えます。各テストは実際の本番シンボルを呼び出し、ネットワーク、実時間、プロセス、実際のファイルシステムへの依存なしに、具体的で決定論的な結果をアサートする必要があります。

既存プロジェクトの配線修復の場合、ユーザーがテスト動作の変更を明示的に要求しない限り、テストを追加、書き換え、名前変更、または拡張しないでください。登録とテストの作成は別々の操作です。

5. 修復した経路を検証する

選択した経路を証明できる、最も範囲の狭いコマンドを実行します。

実際のリポジトリのモードに応じたコマンド形式を選択します。ネイティブ MTP では dotnet test --project <test-project> と dotnet test --solution <entry-point> を使用します。 VSTest コマンドモードでは、MTP へのブリッジを含め、プロジェクト／ソリューションのパスを 位置引数で指定します。この区別は、以下のすべての直接プロジェクトテストとエントリポイント テストに適用してください。CI の正確なコマンドと、サポートされている .slnf の呼び出し方を 維持してください。ソリューションに置き換えたり、サポートされていないスイッチを作り出したり しないでください。 従来型の非 SDK プロジェクトでは、以下の dotnet test の例ではなく、リポジトリに記載された MSBuild およびネイティブテストランナーのコマンドを使用してください。 そのツールチェーンを使用できない場合は、プロジェクトを移行したり、検出に成功したと主張したり せず、障害要因を報告してください。

経路	必要な証拠
新規作成したプロジェクト	モードに応じた直接プロジェクトテスト、CI が使用する正確なエントリポイントコマンド、登録内容の一覧。エントリポイントがテストを含む .slnf／.slnx の場合は、ビルドできることだけを証明するのではなく、その成果物に対してリポジトリのテストコマンドを実行してください。
参照の欠落	対象プロジェクトのテストと、指定された正確なソリューション／ルートテストコマンド
.sln／.slnx 登録の欠落	一覧表示と、その正確な成果物に対する dotnet test。別のソリューションを代替として使用しないでください
.slnf エントリの欠落	フィルターエントリを調べ、正確な CI フィルタービルドコマンドを実行してください。意図的に失敗する別のコマンドを前置しないでください
すでに正しい／変更なし	既存の参照と登録を構造的に確認します。実行が求められていない限り、変更なしを証明するためだけにテストを実行しないでください。bin／obj が作成され、バイト単位で変更がないことを示す証拠が弱まるためです。

スイッチを追加する前に、リポジトリのコマンドを確認してください。推測による --no-restore の試行を前置したり、command-a || command-b のように代替案を隠したりせず、クリーンな終了が証拠となる設定済みの エントリポイントコマンドを実行してください。

配線を修復するたびに、正確な検証コマンドを直接実行し、その終了ステータスを保持してください。 生成ファイル、採点スクリプト、または後続のビルドを読んでも、そのコマンドが正常に完了したことの 確認にはなりません。

完了を報告する前に、最終的な変更ファイル一式を確認してください。このタスクで作成され、 作成前には存在せず、意図的に追跡されているものではない bin／obj または同等の ビルド成果物だけを削除してください。既存の成果物は決して削除しないでください。合格した コマンドの完全な結果を保持し、引き継ぎで正確なエントリポイントと検出されたテスト数を 記載できるようにしてください。

変更なしの場合は、書き換えずに確認し、既存のパスを報告してください。dotnet build の成功は テスト検出の証拠にはなりません。検証が妨げられた場合は、失敗した正確なコマンドと、最初に 対処可能なエラーを報告してください。実行していないコマンドや失敗したコマンドを、成功したと 説明してはいけません。

出力

変更内容に見合った分量で引き継ぎを作成してください。

要件	証拠
プロジェクトの新規作成、再利用、または修復	テストプロジェクトのパスと選択した経路
製品コードの参照	参照された .csproj、または変更が不要だった理由
ビルド登録	正確な .sln／.slnx／.slnf エントリ、またはプロジェクトのワークフロー
テスト検出	成功したハーネスレベルのコマンドと、検出されたテスト

完了チェック

• プロジェクトの作成前に既存プロジェクトを確認した。
• 要求された製品コードの範囲のみを参照し、テストした。
• フレームワーク、ランナー、ターゲットフレームワーク、中央パッケージの規約を維持した。
• 新規作成したプロジェクトからテンプレートのサンプルを削除した。
• 配線のみの修復では、既存のテストコードに手を加えていない。
• リポジトリの正確なエントリポイントで、テストプロジェクトが検出され、実行される。