次の方法で共有

Microsoft.Testing.Platform の概要

  • [アーティクル]

Microsoft.Testing.Platform は、あらゆるコンテキスト (継続的インテグレーション (CI) パイプライン、CLI、Visual Studio テスト エクスプローラー、VS Code テキスト エクスプローラーなど) でテストを実行するための、VSTest に代わる軽量で移植可能な代替手段です。 Microsoft.Testing.Platform はテスト プロジェクトに直接埋め込まれており、テストの実行に必要なvstest.console や dotnet test など、他のアプリの依存関係はありません。

Microsoft.Testing.Platform はオープンソースです。 Microsoft.Testing.Platform のコードは、microsoft/testfx GitHub リポジトリにあります。

Microsoft.Testing.Platform の柱

この新しいテスト プラットフォームは、.NET Developer Experience Testing チームの経験に基づいて構築されており、2016 年の .NET Core のリリース以降に発生した課題に対処することを目的としています。 .NET Framework と .NET Core/.NET の間には高いレベルの互換性がありますが、プラグイン システムや .NET コンパイルの新しい可能なフォーム ファクターなどの一部の主要な機能により、現在の VSTest プラットフォーム アーキテクチャで新しいランタイム機能を進化または完全にサポートすることが複雑になりました。

新しいテスト プラットフォームの進化の主な推進要因については、以下で詳しく説明します。

  • 決定主義: 異なるコンテキスト (ローカル、CI) で同じテストを実行すると、同じ結果が生成されることを確認します。 新しいランタイムは、リフレクションやその他の動的な .NET ランタイム機能に依存してテストの実行を調整しません。

  • ランタイムの透過性: テスト ランタイムはテスト フレームワーク コードに干渉せず、 AppDomain や AssemblyLoadContextなどの分離されたコンテキストを作成せず、リフレクションまたはカスタム アセンブリ リゾルバーを使用しません。

  • 拡張機能のコンパイル時の登録: テスト フレームワークやプロセス外の拡張機能などの拡張機能は、確定性を確保し、不整合の検出を容易にするためにコンパイル時に登録されます。

  • 依存関係がゼロ: プラットフォームのコアは、サポートされているランタイム以外の依存関係を持たない単一の .NET アセンブリである Microsoft.Testing.Platform.dllです。

  • Hostable: テスト ランタイムは、任意の .NET アプリケーションでホストできます。 コンソール アプリケーションはテストの実行に一般的に使用されますが、任意の種類の .NET アプリケーションでテスト アプリケーションを作成できます。 これにより、制限がある可能性があるデバイスやブラウザーなどの特殊なコンテキスト内でテストを実行できます。

  • すべての .NET フォーム ファクターをサポート: ネイティブ AOT を含む、現在および将来の .NET フォーム ファクターをサポートします。

  • パフォーマンス: 機能と拡張ポイントの間の適切なバランスを見つけ、基本以外のコードでランタイムが肥大化しないようにします。 新しいテスト プラットフォームは、テストの実行方法に関する実装の詳細を提供するのではなく、テスト実行を "調整" するように設計されています。

  • 十分に拡張可能: 新しいプラットフォームは、ランタイム実行を最大限にカスタマイズできるように拡張ポイントに基づいて構築されています。 テスト プロセス ホストを構成し、テスト プロセスを観察し、テスト ホスト プロセス内でテスト フレームワークからの情報を使用することができます。

  • 1 つのモジュールデプロイ: ホスト機能を使用すると、単一のモジュールデプロイ モデルを使用できます。このモデルでは、1 つのコンパイル結果を使用して、アウトプロセスとインプロセスの両方のすべての機能拡張ポイントをサポートできます。異なる実行可能モジュールを出荷する必要はありません。

サポートされるテスト フレームワーク

  • プロジェクトです。 MSTest では、Microsoft.Testing.Platform のサポートは MSTest ランナーを介して行われます。
  • NUnit。 NUnit では、Microsoft.Testing.Platform のサポートは NUnit ランナーを介して行われます。
  • xUnit.net: xUnit.net では、Microsoft.Testing.Platform のサポートは xUnit.net ランナーを介して行われます。
  • TUnit: 完全に Microsoft.Testing.Platform上に構築されています。詳細については、 TUnit ドキュメントを参照してください。

テストを実行およびデバッグする

Microsoft.Testing.Platform テスト プロジェクトは、直接実行 (またはデバッグ) できる実行可能ファイルとしてビルドされます。 コンソールやコマンドを実行する追加のテストはありません。 ほとんどの実行可能ファイルでよくあるように、エラーが発生すると、アプリはゼロ以外の終了コードで終了します。 既知の終了コードの詳細については、「Microsoft.Testing.Platform の終了コード」を参照してください。

重要

既定では、Microsoft.Testing.Platform はテレメトリを収集します。 オプトアウトの詳細とオプションについては、「Microsoft.Testing.Platform テレメトリ」を参照してください。

テストを実行する別の方法として、dotnet publish を使用してテスト プロジェクトを発行し、アプリを直接実行します。 たとえば、./Contoso.MyTests.exe を実行します。 一部のシナリオでは、dotnet build を使って実行可能ファイルを生成することもできますが、ネイティブ AOT などのエッジ ケースを考慮する必要がある場合があります。

dotnet run を使用します

dotnet run コマンドを使用して、テスト プロジェクトをビルドして実行できます。 これはテストを実行する最も簡単な方法ですが、最も時間がかかることがあります。 dotnet run を使用すると、必要に応じてテスト プロジェクトが確実に再作成されるため、ローカルでテストを編集したり実行したりする場合に役立ちます。 dotnet run は、現在のフォルダー内のプロジェクトも自動的に検索します。

dotnet run --project Contoso.MyTests

dotnet run の詳細については、「dotnet run」を参照してください。

dotnet exec を使用します

dotnet exec または dotnet コマンドは、既にビルドされているテスト プロジェクトを実行するために使われます。これは、アプリケーションを直接実行する代わりの方法です。 dotnet exec には、ビルドされたテスト プロジェクトの dll へのパスが必要になります。

dotnet exec Contoso.MyTests.dll

or

dotnet Contoso.MyTests.dll

Note

テスト プロジェクト実行可能ファイル (*.exe) へのパスを指定すると、次のエラーが発生します。

Error:
  An assembly specified in the application dependencies manifest
  (Contoso.MyTests.deps.json) has already been found but with a different
  file extension:
    package: 'Contoso.MyTests', version: '1.0.0'
    path: 'Contoso.MyTests.dll'
    previously found assembly: 'S:\t\Contoso.MyTests\bin\Debug\net8.0\Contoso.MyTests.exe'

dotnet exec の詳細については、dotnet exec に関するページを参照してください。

dotnet test を使用します

Microsoft.Testing.Platform には、vstest.console.exe および dotnet test との互換性レイヤーが用意されており、新しい実行シナリオを有効にしながら、以前と同様にテストを実行できるようにします。

dotnet test Contoso.MyTests.dll

[オプション]

以下の一覧では、プラットフォーム オプションのみを説明しています。 各拡張機能によって提供される特定のオプションを表示するには、拡張機能のドキュメント ページを参照するか、--help オプションを使用します。

  • --diagnostic

診断ログを有効にします。 デフォルトのログ レベルは Trace です。 ファイルは、次の名前形式 log_[MMddHHssfff].diag で出力ディレクトリに書き込まれます。

  • --diagnostic-filelogger-synchronouswrite

組み込みのファイル ロガーにログの同期的な書き込みを強制します。 (プロセスがクラッシュした場合に) ログ エントリを少しも失いたくないときのシナリオに役立ちます。 これにより、テストの実行速度は低下します。

  • --diagnostic-output-directory

指定しない場合、診断ログの出力ディレクトリとして、ファイルはデフォルトの TestResults ディレクトリに生成されます。

  • --diagnostic-output-fileprefix

ログ ファイル名のプレフィックス。 既定値は "log_" です。

  • --diagnostic-verbosity

--diagnostic スイッチを使用するときの詳細レベルを定義します。 使用できる値は Trace、Debug、Information、Warning、Error、Critical です。

  • --help

コマンドの使用方法を示した説明を出力します。

  • -ignore-exit-code

一部の 0 以外の終了コードを無視し、代わりに 0 として返すようにします。 詳細については、「特定の終了コードを無視する」を参照してください。

  • --info

.NET テスト アプリケーションに関する次のような詳細情報を表示します。

  • プラットフォーム。
  • 環境。
  • 登録済みの各コマンド ライン プロバイダー (name、version、description、optionsなど)
  • 登録済みの各ツール (command、name、version、descriptionなど) と、すべてのコマンド ライン プロバイダー。

この機能は、同じコマンド ライン オプションを登録する拡張機能や、拡張機能 (またはプラットフォーム) の複数のバージョン間で使用可能なオプションの変更を理解するのに使用されます。

  • --list-tests

使用可能なテストを一覧表示します。 テストは実行されません。

  • --minimum-expected-tests

実行する必要があるテストの最小数を指定します。 既定では、少なくとも 1 つのテストが実行されることが想定されています。

  • --results-directory

テスト結果が配置されるディレクトリです。 指定されたディレクトリが存在しない場合は、作成されます。 既定値は、テスト アプリケーションを含むディレクトリ内の TestResults です。

MSBuild の統合

NuGet パッケージ Microsoft.Testing.Platform.MSBuild は、 Microsoft.Testing.Platform と MSBuild のさまざまな統合を提供します。

  • dotnet test をサポートします。 詳細については、 dotnet test integrationを参照してください。
  • Visual Studio および Visual Studio Code テスト エクスプローラーに必要な ProjectCapability のサポート。
  • エントリポイントの自動生成（Main メソッド）。
  • 設定ファイルの自動生成。

Note

この統合は推移的に機能し (このパッケージを参照する別のプロジェクトを参照するプロジェクトは、パッケージを参照しているかのように動作します)、 IsTestingPlatformApplication MSBuild プロパティを通じて無効にすることができます。

関連項目