Microsoft。Testing.Platform (MTP) のトラブルシューティング

この記事には、MTP のトラブルシューティングガイダンスが含まれています。

`dotnet test` レポート `No test projects were found`

dotnet testソリューションまたはプロジェクトに対して MTP モードで実行すると、プロジェクトが評価され、IsTestingPlatformApplicationを使用して MTP テストアプリケーションが識別されます。テストフレームワークとプラットフォームパッケージは、通常、NuGet MSBuild のインポートによってこのプロパティを設定します。

暗黙的な復元により、パッケージのインポートが使用可能になります。ただし、マルチステージコンテナービルドでは、次の両方の条件が当てはまる場合、 dotnet test は No test projects were found を報告できます。

テストステージでは、 --no-restore または --no-buildが使用されます。これは、 --no-restoreを意味します。
テストステージには、復元によって生成されたプロジェクトの状態が obj フォルダーに含まれていないか、復元ステージで使用された完全なグローバルパッケージフォルダーが含まれません。

パッケージをインポートしないと、 IsTestingPlatformApplication は空の値に評価されるため、 dotnet test はプロジェクトを MTP テストアプリケーションとして分類しません。この問題は、MSTest に固有の問題ではありません。

この問題を解決するには、次のいずれかの方法を使用します。

dotnet testを実行する前に、テストステージでプロジェクトを復元します。
復元によって生成された obj フォルダーと、復元ステージから完全なグローバルパッケージフォルダーをコピーまたは保持します。 obj フォルダーには、project.assets.json、*.nuget.g.props、*.nuget.g.targetsなどのファイルが含まれています。 NUGET_PACKAGESまたはRestorePackagesPathを設定した場合は、その構成された場所にグローバルパッケージフォルダーを保持します。
テストステージに既にビルドされているテストアプリケーションが含まれているが、プロジェクトの復元状態が含まれていない場合は、 dotnet test --test-modules <EXPRESSION>を使用します。このオプションでは、プロジェクト評価なしでビルドされたテストモジュールが選択されます。

終了コード

MTP は既知の終了コードを使用して、テストエラーまたはアプリエラーを伝えます。終了コードは 0 から始まり、負以外の値になります。

終了コード	詳細情報
`0`	`0`終了コードは成功を示します。実行するように選択されたすべてのテストは完了まで実行され、エラーはありませんでした。
`1`	`1`終了コードは、不明なエラーを示し、あらゆるものを処理するように機能します。追加のエラー情報と詳細を確認するには、出力を確認します。
`2`	`2`の終了コードは、少なくとも 1 つのテストエラーが発生したことを示すために使用されます。
`3`	終了コード `3` は、テストセッションが中止されたことを示します。例として、Ctrl+`を`使用してセッションを中止できます。
`4`	終了コード `4` は、使用されている拡張機能のセットアップが無効であり、テストセッションを実行できないことを示します。
`5`	終了コード `5` は、テストアプリに渡されたコマンドライン引数が無効であることを示します。
`6` (使用されなくなりました)	終了コード `6` はプラットフォームによって生成されなくなりました。テストセッションが実装されていない機能を使用していることを以前に示していました。
`7`	終了コード `7` は、テストセッションが正常に完了できず、クラッシュした可能性があることを示します。これは、テストコントローラーの拡張ポイントを介して実行されたテストセッションによって発生した可能性があります。
`8`	終了コード `8` は、テストセッションでテストが検出されなかったか、選択したすべてのテストが厳密な `--zero-tests-policy`でスキップされたことを示します。
`9`	終了コード `9` は、実行が実行されたテスト数が、明示的な `--minimum-expected-tests` 値に必要なテスト数 (ゼロテストを含む) よりも少なかったことを示します。
`10`	終了コード `10` は、テストアダプター、Testing.Platform Test Framework、MSTest、NUnit、または xUnit が、テストの自己に関係のないインフラストラクチャの理由でテストを実行できなかったことを示します。たとえば、テストで必要なフィクスチャを作成できないことがあります。
`11`	終了コード `11` は、依存プロセスが終了した場合にテストプロセスが終了することを示します。
`12`	終了コード `12` は、クライアントがサポートされているプロトコルバージョンをサポートしていないため、テストセッションを実行できなかったことを示します。
`13`	終了コード `13` は、コマンドラインオプションを使用して、指定された失敗したテストの最大数に達したため、テストセッション `--maximum-failed-tests` 停止したことを示します。詳細については、MTP CLI オプションリファレンスの「オプション」セクションを参照してください。
`14`	終了コード `14` は、互換性のあるカバレッジコレクターによって、カバレッジしきい値評価の失敗が報告されたことを示します。

明示的な --minimum-expected-tests 値が --zero-tests-policyよりも優先されます。最小オプションがない場合、厳密なゼロテスト処理では、終了コード 8が引き続き使用されます。終了コード 8 と 9 は異なるままであるため、アンメット最小値はテストを実行しなかったモジュールと混同されません。

詳細ログを有効にし、問題のトラブルシューティングを行うには、診断ログを参照してください。

マルチモジュール実行時のテスト0件

dotnet test複数のテストモジュールを実行する場合、終了コード 8はモジュールごとのシグナルですが、実行全体に対するゼロテストの判定は集計結果から 1 回決定されます。そのため、単一の空のモジュールは実行全体を失敗しませんが、モジュールは出力に Exit code: 8 診断を保持します。グローバル最小値を設定しない場合、モジュールごとの --zero-tests-policy 値に関係なく、すべてスキップされた実行全体がゼロテスト実行として扱われます。詳細については、「実行全体とモジュールごとの最小値」を参照してください。

注

この 0 回のテスト全体の判定には、.NET 11 SDK 以降のバージョンが必要です。

特定の終了コードを無視する

MTP は既定で厳密に設計されていますが、構成が可能です。そのため、無視する終了コードをユーザーが決定できます (元の終了コードではなく、 0 の終了コードが返されます)。

特定の終了コードを無視するには、 --ignore-exit-code コマンドラインオプションまたは TESTINGPLATFORM_EXITCODE_IGNORE 環境変数を使用します。有効な形式は、無視する終了コードのセミコロン区切りのリストです (例: --ignore-exit-code 2;3;8)。一般的なシナリオは、テストの失敗が 0 以外の終了コード (終了コードの 2の無視に対応する) になってはいけないことを考慮することです。

診断ログ

このプラットフォームには、テスト実行のトラブルシューティングに役立つ組み込みの診断ログが用意されています。コマンドラインオプションまたは環境変数を使用して診断ログを有効にすることができます。

コマンドラインオプション

次のプラットフォームオプションは、テストアプリのトラブルシューティングに役立つ情報を提供します。

--info
--diagnostic
--diagnostic-synchronous-write
--diagnostic-verbosity
--diagnostic-file-prefix
--diagnostic-output-directory

環境変数

環境変数を使用して診断ログを有効にすることもできます。

環境変数の名前	[説明]
`TESTINGPLATFORM_DIAGNOSTIC`	`1`に設定すると、診断ログが有効になります。
`TESTINGPLATFORM_DIAGNOSTIC_VERBOSITY`	詳細レベルを定義します。使用できる値は `Trace`、`Debug`、`Information`、`Warning`、`Error`、`Critical` です。
`TESTINGPLATFORM_DIAGNOSTIC_OUTPUT_DIRECTORY`	指定しない場合、診断ログの出力ディレクトリとして、ファイルはデフォルトの TestResults ディレクトリに生成されます。
`TESTINGPLATFORM_DIAGNOSTIC_FILE_PREFIX`	ログファイル名のプレフィックス。既定値では、 `<asm>_<tfm>_<arch>_<timestamp>.diag`が生成されます。バージョン 2.3.0 以降の MTP で使用できます。従来の名前 `TESTINGPLATFORM_DIAGNOSTIC_OUTPUT_FILEPREFIX` は、下位互換性のために引き続き使用されます。
`TESTINGPLATFORM_DIAGNOSTIC_SYNCHRONOUS_WRITE`	組み込みのファイルロガーにログの同期的な書き込みを強制します。 (プロセスがクラッシュした場合に) ログエントリを少しも失いたくないときのシナリオに役立ちます。これにより、テストの実行速度は低下します。バージョン 2.3.0 以降の MTP で使用できます。従来の名前 `TESTINGPLATFORM_DIAGNOSTIC_FILELOGGER_SYNCHRONOUSWRITE` は、下位互換性のために引き続き使用されます。

注

環境変数は、コマンドライン引数よりも優先されます。

MTP は、各テストソースの診断ファイルを書き込みます。 2 つのファイルが同じタイムスタンプを受け取った場合、MTP は既存のファイルを上書きするのではなく、プロセスとカウンターサフィックスを追加します。

構成エラーを解決する

Microsoft.Testing.Platform.MSBuild

Microsoft.Testing.Platform.MSBuild に関連する一般的な構成エラーを次に示します。

エラー CS8892: 同期エントリポイント 'Program.Main(string[])' が見つかったため、メソッド 'TestingPlatformEntryPoint.Main(string[])' はエントリポイントとして使用されません

テストプロジェクトでエントリポイント (Main) を手動で定義するか、既にエントリポイントがあるアプリケーションからテストプロジェクトを参照すると、MTP によって生成されたエントリポイントと競合します。この問題を回避するには、次のいずれかの手順を実行します。

手動で定義されたエントリポイント (通常は Program.cs のメソッドMain) を削除し、テストプラットフォームで生成できるようにします。
<GenerateTestingPlatformEntryPoint>false</GenerateTestingPlatformEntryPoint> MSBuild プロパティを設定して、エントリポイントの生成を無効にします。
テストプロジェクトを参照するプロジェクトでMicrosoft.Testing.Platform.MSBuild MSBuild プロパティを設定して、推移的な依存関係を<IsTestingPlatformApplication>false</IsTestingPlatformApplication>に完全に無効にします。これは、テストアプリケーションを参照するコンソールアプリなど、テスト以外のプロジェクトからテストプロジェクトを参照する場合に必要です。

生成されたコード名前空間が参照先の型と競合する

Microsoft.Testing.Platform.MSBuild は、プロジェクトの SelfRegisteredExtensions 内に TestingPlatformEntryPoint 型と $(RootNamespace) 型を生成します。既定では、 RootNamespace はプロジェクト名と一致します。これは、参照アセンブリによって公開されている同じ完全修飾名の型と競合する可能性があります。

たとえば、 System.Security.Cryptography.ProtectedData.Tests という名前のプロジェクトでは、 System.Security.Cryptography.ProtectedData 名前空間にコードが生成されます。プロジェクトが、System.Security.Cryptography.ProtectedData名前空間の下にパブリックProtectedData型を含むSystem.Security.Cryptography NuGet パッケージも参照する場合、コンパイラは生成された名前空間と参照先の型の間であいまいさを解消できなくなり、CS0118などのエラーが出力されます ("ProtectedData" は名前空間ですが、型のように使用されます)。

競合を解決するには、テストプロジェクトの RootNamespace を、参照先の型と競合しない値にオーバーライドします。

<PropertyGroup>
  <RootNamespace>System.Security.Cryptography.ProtectedDataTests</RootNamespace>
</PropertyGroup>

RootNamespace全体 (<RootNamespace />) をクリアすることもできます。その場合、生成された型はグローバル名前空間に出力されます。

Microsoft.Testing.Extensions.Fakes

テスト用に "COR_PROFILER_PATH および COR_PROFILER 環境変数からプロファイラーパスを解決できませんでした" というエラーを偽装します

このエラーは、すべての Fakes アセンブリが bin フォルダーに存在しない場合に発生する可能性があります。

プロジェクトで MSTest.SDK を使用するか、 Microsoft.Testing.Extensions.Fakes を参照していることを確認します。
.NET Framework プロジェクトの場合は、nuGet ですべてのファイルが bin フォルダーにコピーされないため、<PlatformTarget>AnyCPU</PlatformTarget> を設定しないでください。

認識されない拡張機能のコマンドラインオプション

拡張機能固有のコマンドラインオプションは、テストアプリケーションがオプションを提供するパッケージを登録しない場合、終了コード 5 で失敗する可能性があります。たとえば、 --report-trx は、直接パッケージ参照として、またはパッケージを含むテスト SDK 構成またはプロファイルを使用して、 Microsoft.Testing.Extensions.TrxReportを必要とします。 MTP コアには、レポート、コードカバレッジ、ダンプ、再試行、またはその他の拡張機能オプションは含まれません。

--helpを使用してテストアプリケーションを実行するか、MTP モードでdotnet test --help実行して、オプションが使用可能であることを確認します。オプションがない場合は、その拡張機能パッケージを追加するか、テスト SDK を使用して拡張機能を有効にします。必要なパッケージを見つけるには、シナリオ別の拡張機能オプションを参照してください。

同じエラーが発生するのは、異なるテストフレームワーク (MSTest や xUnit.net など) を使用するプロジェクトまたは異なる拡張機能のセット (たとえば、一部のプロジェクトのみが参照 Microsoft.Testing.Extensions.HangDump) を使用するプロジェクトがソリューションに含まれている場合です。このオプションは 1 つのプロジェクトで有効ですが、別のプロジェクトでは認識されません。

この問題を解決するには、 TestingPlatformCommandLineArguments MSBuild プロパティと条件を使用して、引数を正しいプロジェクトにルーティングします。詳細な手順については、「テストフレームワークまたは拡張機能が混在するソリューション」を参照してください。

フィードバック

このページはお役に立ちましたか?

最終更新: 2026-09-23