VSTest から Microsoft.Testing.Platform (MTP) に移行します。

この記事では、VSTest から MTP に移行する方法について説明します。

この記事では、移行手順と引数マッピングについて説明します。

それでもプラットフォームを選択する必要がある場合は、テストプラットフォームの概要から始めます。

dotnet test モードの詳細な動作が必要な場合は、「dotnet testを使用したテスト」を参照してください。

プラットフォームと拡張機能のコマンドラインオプションの 1 つの一覧が必要な場合は、 MTP CLI オプションのリファレンスを参照してください。

MTP の使用をオプトインする

移行の最初の手順は、MTP の使用をオプトインすることです。

すべてのテストフレームワークについて、ソリューション内のすべてのテストプロジェクトに <OutputType>Exe</OutputType> を追加します。その後、フレームワーク固有のガイダンスに従います。

MSTest

MTP は、3.2.0 以降の MSTest でサポートされています。ただし、利用可能な最新の MSTest バージョンに更新することをお勧めします。

オプトインするには、ファイル内の<EnableMSTestRunner>true</EnableMSTestRunner>の下にPropertyGroupDirectory.Build.props追加します。

注

MSTest.Sdk を使用する場合は、 <UseVSTest>true</UseVSTest> が指定されていない限り、MTP が既定で使用されます。

NUnit

MTP は、5.0.0 以降の NUnit3TestAdapter でサポートされています。

オプトインするには、ファイル内の<EnableNUnitRunner>true</EnableNUnitRunner>の下にPropertyGroupDirectory.Build.props追加します。

xUnit.net

MTP は xunit.v3 以降でサポートされています。

オプトインするには、ファイル内の<UseMicrosoftTestingPlatformRunner>true</UseMicrosoftTestingPlatformRunner>の下にPropertyGroupDirectory.Build.props追加します。

`dotnet test`

.NET 9 SDK 以前への参加申し込み

.NET 9 SDK 以前では、用の MTP のサポートは dotnet test ありません。サポートは VSTest インフラストラクチャの上に構築されています。これを使用するには、ファイル内の<TestingPlatformDotnetTestSupport>true</TestingPlatformDotnetTestSupport>の下にPropertyGroupDirectory.Build.props追加します。

Important

このモードで MTP サポートを実行する場合は、--引数を新しいプラットフォーム引数から分離するためにdotnet testを追加する必要があります。たとえば、「 dotnet test --no-build -- --list-tests 」のように入力します。

.NET 10 SDK 以降にオプトインする

.NET 10 SDK 以降では、MTP のサポートnativeがあります。これを使用するには、Microsoft.Testing.Platformランナーをとして指定する必要があります。

{
  "test": {
    "runner": "Microsoft.Testing.Platform"
  }
}

Important

このモードでは、余分な -- は使用されなくなりました。

`dotnet test`呼び出しを更新する

dotnet testのコマンドラインオプションは、ビルド関連の引数とテスト関連の引数の 2 つのカテゴリに分かれています。

ビルド関連の引数はテストプラットフォームとは無関係であり、新しいプラットフォーム用に更新する必要はありません。ビルド関連の引数を次に示します。

-a|--arch <ARCHITECTURE>
--artifacts-path <ARTIFACTS_DIR>
-c|--configuration <CONFIGURATION>
-f|--framework <FRAMEWORK>
-e|--environment <NAME="VALUE">
--interactive
--no-build
--nologo
--no-restore
-o|--output <OUTPUT_DIRECTORY>
--os <OS>
-r|--runtime <RUNTIME_IDENTIFIER>
-v|--verbosity <LEVEL>

テスト関連の引数は VSTest 固有であるため、新しいプラットフォームに合わせて変換する必要があります。次の表に、VSTest 引数と新しいプラットフォームの間のマッピングを示します。

VSTest 引数	新しいプラットフォーム引数
`--test-adapter-path <ADAPTER_PATH>`	MTP には関係ありません
`--blame`	MTP には関係ありません
`--blame-crash`	`--crashdump` ( クラッシュダンプ拡張機能が必要)
`--blame-crash-dump-type <DUMP_TYPE>`	`--crashdump-type` ( クラッシュダンプ拡張機能が必要)
`--blame-crash-collect-always`	サポートされていません
`--blame-hang`	`--hangdump` (要ハングダンプ拡張機能)
`--blame-hang-dump-type <DUMP_TYPE>`	`--hangdump-type` (要ハングダンプ拡張機能)
`--blame-hang-timeout <TIMESPAN>`	`--hangdump-timeout` (要ハングダンプ拡張機能)
`--collect <DATA_COLLECTOR_NAME>`	データコレクターに依存
`-d\\|--diag <LOG_FILE>`	`--diagnostic`
`--filter <EXPRESSION>`	選択したテストフレームワークによって異なります
`-l\\|--logger <LOGGER>`	ロガーに依存
`--results-directory <RESULTS_DIR>`	`--results-directory <RESULTS_DIR>`
`-s\\|--settings <SETTINGS_FILE>`	選択したテストフレームワークによって異なります
`-t\\|--list-tests`	`--list-tests`
`-- <RunSettings arguments>`	`--test-parameter` ( VSTestBridge によって提供)

`--collect`

--collect は、任意のデータコレクターの VSTest の一般的な拡張ポイントです。 MTP の拡張性モデルは異なり、すべてのデータコレクターで使用されるこのような一元的な引数はありません。 MTP を使用すると、各データコレクターは独自のコマンドラインオプションを追加できます。たとえば、VSTest を使用して Microsoft CodeCoverage を実行すると、次のようになります。

dotnet test --collect "Code Coverage;Format=cobertura"

MTP では、次のようになります。

dotnet test --coverage --coverage-output-format cobertura

Important

前述のように、VSTest ベースの dotnet testで MTP を使用する場合は、プラットフォームに渡す引数の前に追加の -- が必要です。そのため、これは dotnet test -- --coverage --coverage-output-format coberturaになります。

`--filter`

--filter は VSTest ベースのフィルターです。

MSTest と NUnit は、MTP で実行されている場合でも、同じフィルター形式をサポートします。

xUnit.net、MTP を使用して実行する場合、同じフィルター形式はサポートされません。次のコマンドラインオプションを使用して、VSTest ベースのフィルターから xunit.v3 の新しいフィルターサポートに移行する必要があります。

xUnit.net の特定オプション

--filter-class
--filter-not-class
--filter-method
--filter-not-method
--filter-namespace
--filter-not-namespace
--filter-trait
--filter-not-trait
--filter-query

詳細については、xUnit.net の Microsoft.Testing.Platform ドキュメントと、xUnit.net のクエリフィルター言語に関するドキュメントを参照してください。

`--logger`

通常、VSTest では "logger" と呼ばれていましたが、MTP では "レポーター" と呼ばれます。 MTP では、ログ記録は診断目的でのみ明示的に行われます。

--collectと同様に、--loggerは、任意のロガー (または MTP のコンテキストでは任意のレポーター) に対する VSTest の一般的な拡張ポイントです。各 MTP レポーターは、独自のコマンドラインオプションを自由に追加できます。そのため、VSTest の --loggerのような一元化されたコマンドラインオプションはありません。

非常に一般的に使用される VSTest ロガーの 1 つは、TRX ロガーです。通常、このロガーは次のように呼び出されます。

dotnet test --logger trx

MTP では、コマンドは次のようになります。

dotnet test --report-trx

Important

--report-trxを使用するには、Microsoft.Testing.Extensions.TrxReport NuGet パッケージがインストールされている必要があります。

Important

前述のように、VSTest ベースの dotnet testで MTP を使用する場合は、プラットフォームに渡す引数の前に追加の -- が必要です。そのため、これは dotnet test -- --report-trxになります。

`--settings`

VSTest の --settings は、テスト実行の RunSettings ファイルを指定するために使用されます。 RunSettings はコア MTP ではサポートされておらず、より最新の testconfig.json 構成ファイルに置き換えられました。ただし、MSTest と NUnit では、MTP の実行時に古い RunSettings が引き続きサポートされ、 --settings は引き続きサポートされます。

`vstest.console.exe`

vstest.console.exeを直接使用している場合は、dotnet test コマンドに置き換えることをお勧めします。

テストエクスプローラ

Visual Studio Test ExplorerまたはVisual Studio Codeを使用する場合、MTPのサポートを有効にする必要があるかもしれません。

Visual Studio

Visual Studio テストエクスプローラーでは、バージョン 17.14 以降の MTP がサポートされています。以前のバージョンを使用している場合は、Visual Studio を最新バージョンに更新することが必要になる場合があります。

Visual Studio Code

C# DevKit を使用したVisual Studio Codeでは MTP がサポートされます。

Azure DevOps

Azure DevOpsタスクを使用する場合は、使用するタスクに応じて、MTP を使用するようにパイプラインを更新することが必要になる場合があります。

VSTest タスク

Azure DevOps で VSTest タスクを使用している場合は、 .NET Core タスクに置き換えることができます。

.NET Core CLI タスク

タスクにカスタム arguments が渡されている場合は、 dotnet test 移行の同じガイダンスに従ってください。
.NET 10 SDK以降でネイティブMTPエクスペリエンスをglobal.jsonファイルを使ってオプトインせずにDotNetCoreCLIタスクを使用する場合は、タスクargumentsを以前に指定された結果ディレクトリと要求されたTRXレポートを正しく指すように設定し直す必要があります。例えば次が挙げられます。
```
- task: DotNetCoreCLI@2
  displayName: Run unit tests
  inputs:
    command: 'test'
    arguments: '-- --report-trx --results-directory $(Agent.TempDirectory)'
```

VSTest と MTP の動作の違い

ゼロテストの実行

テストアセンブリでゼロテストが実行された場合、VSTest はそのテストを許容し、成功して終了します。ただし、MTP は終了コード 8 で失敗します。この問題を回避するには、複数の方法があります。

テストを実行する際に--ignore-exit-code 8を渡します。

特定のテストプロジェクトの終了コードを無視する場合は、プロジェクトファイルに次のコードを追加します。

<PropertyGroup>
  <TestingPlatformCommandLineArguments>$(TestingPlatformCommandLineArguments) --ignore-exit-code 8</TestingPlatformCommandLineArguments>
</PropertyGroup>

TESTINGPLATFORM_EXITCODE_IGNORE環境変数を使用します。

Console.InputEncoding の保持

コードページが明示的に変更されたコンソールでテストを実行する場合 (たとえば、Azure DevOpsでは、コードページは UTF8 に対応する 65001 に設定されます)、VSTest と MTP で動作が異なる場合があります。

MTP では、そのエンコードは常に保持されます。
VSTest が分離モード (vstest.console の既定の動作) で実行されていない場合、そのエンコードは MTP と同様に保持されます。
VSTest が分離モード ( dotnet test の既定の動作) で実行されている場合、そのエンコードは testhost (テストを実行するプロセス) に保持されません。

ヒント

エンコードが VSTest 分離モードで保持されない理由は、testhost プロセスが CreateNoWindow = true で開始されるためです。そのため、元の本体にはアタッチされません。

別の子プロセスを開始し、その標準出力をリダイレクトするテストがある場合は、次のすべてが該当する場合に問題が発生する可能性があります。

コンソールのコードページは 65001 (UTF8) に設定されています。これは CI では当てはまる可能性がありますが、一般的にはローカル環境には適用されません。 CI と同様のローカル動作を取得するには、テストを実行する前に chcp 65001 を実行します。
子プロセスは、UTF8 以外のエンコードで開始されます。これは、独自のテストで CreateNoWindow = trueも設定している場合にも発生する可能性があります。

これは、子プロセスが UTF8 BOM (Byte-Order-Mark) バイトを想定していない場合に特に問題になります。これは、.NET Framework 上の以前のシナリオで発生する可能性があります。

この動作の違いは BOM バイトに特に問題がある可能性が高く、回避策として、アセンブリの初期化中に InputEncoding を BOM なしで UTF8 に設定します。

Console.InputEncoding = new UTF8Encoding(encoderShouldEmitUTF8Identifier: false);

その別の回避策は、標準入力をリダイレクトする子プロセスに CreateNoWindow = true を使用しないことです。

フィードバック

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

Last updated on 2026-04-27

VSTest から Microsoft.Testing.Platform (MTP) に移行します。

MTP の使用をオプトインする

MSTest

NUnit

xUnit.net

dotnet test

.NET 9 SDK 以前への参加申し込み

.NET 10 SDK 以降にオプトインする

dotnet test呼び出しを更新する

--collect

--filter

--logger

--settings

vstest.console.exe

テスト エクスプローラ

Visual Studio

Visual Studio Code

Azure DevOps

VSTest タスク

.NET Core CLI タスク

VSTest と MTP の動作の違い

ゼロ テストの実行

Console.InputEncoding の保持

フィードバック

その他のリソース

`dotnet test`

`dotnet test`呼び出しを更新する

`--collect`

`--filter`

`--logger`

`--settings`

`vstest.console.exe`

テストエクスプローラ

ゼロテストの実行