MTP のコンテキストでは、 機能 とは、 特定のアクションを実行したり、特定の情報を提供したりする可能性を指します。 これは、テスト フレームワークと拡張機能が特定の方法で動作する能力を宣言したり、要求者に特定の情報を提供したりする手段です。
要求者には、プラットフォーム、拡張機能、テスト フレームワーク自体など、テスト セッションに関係する任意のコンポーネントを指定できます。
機能システムの主な目的は、テスト セッションに関係するコンポーネント間の効果的な通信を容易にし、情報をexchangeし、それぞれのニーズを正確に満たすことです。
ガイド付き例
機能システムの必要性を示す架空の例を考えてみましょう。
注
この例は説明のみを目的としており、現在、MTP またはテスト フレームワーク内には実装されていません。
テストフレームワークが一度に1つのテストのみを実行する必要がある拡張機能の状況を想像してください。 さらに、各テストの後、拡張機能はその特定のテストの CPU 使用率を認識する必要があります。
上記のシナリオに対応するには、次の場合にテスト フレームワークから問い合わせる必要があります。
- 一度に 1 つのテストのみを実行する機能があります。
- 各テストで使用される CPU の量に関する情報を提供できます。
拡張機能は、テスト フレームワークがこのモードで動作し、テスト セッションの CPU 使用率情報を提供する機能を持っているかどうかを判断するにはどうすればよいですか? MTP では、この機能は Microsoft.Testing.Platform.Capabilities.ICapability インターフェイスの実装によって表されます。
// Base capabilities contracts
public interface ICapability
{
}
public interface ICapabilities<TCapability>
where TCapability : ICapability
{
IReadOnlyCollection<TCapability> Capabilities { get; }
}
// Specific testing framework capabilities
public interface ITestFrameworkCapabilities : ICapabilities<ITestFrameworkCapability>
{
}
public interface ITestFrameworkCapability : ICapability
{
}
ご覧のように、ICapability インターフェイスは任意の機能を表すことができるため、マーカー インターフェイスであり、実際の実装はコンテキストに依存します。 また、ITestFrameworkCapabilityから継承して機能を分類するICapabilityも確認します。 機能システムの一般的な性質により、コンテキストによる便利なグループ化が可能になります。
ITestFrameworkCapabilityは、テスト フレームワークによって実装されるすべての機能をグループ化します。
ICapabilities<TCapability> インターフェイスは、拡張機能によって実装されるすべての機能のセットを明らかにします。 同様に、基本フレームワークには、 ITestFrameworkCapabilitiesと呼ばれるコンテキスト固有のテスト フレームワークがあります。
ITestFrameworkCapabilitiesは、テスト フレームワークの登録プロセス中にプラットフォームに提供されます。
前述のシナリオに対応する機能を作成するには、次のように定義します。
public interface IDisableParallelismCapability : ITestFrameworkCapability
{
bool CanDisableParallelism { get; }
bool CanProvidePerTestCpuConsumption { get; }
void Enable();
}
テスト フレームワークがこのインターフェイスを実装している場合は、実行時に次のクエリを実行できます。
- テスト フレームワークに並列処理
CanDisableParallelism = trueを無効にする機能があるかどうかを確認します。 - テスト フレームワークが CPU 使用率データを
CanProvidePerTestCPUConsumption = true提供できるかどうかを判断します。 - テスト セッションが開始される前に、
Enable()メソッドを呼び出して、テスト アダプターにこのモードのアクティブ化を要求します。
拡張機能内の架空のコード フラグメントは、次のようになります。
IServiceProvider serviceProvider = null; // TODO: Get IServiceProvider.
var capabilities = serviceProvider.GetRequiredService<ITestFrameworkCapabilities>();
// Utilize the `GetCapability` API to search for the specific capability to query.
var capability = capabilities.GetCapability<IDisableParallelismCapability>();
if (capability is null)
{
// Capability not supported...
}
else
{
capability.Enable();
if (capability.CanDisableParallelism)
{
// Do something...
}
if (capability.CanProvidePerTestCpuConsumption)
{
// Do something...
}
}
前の例では、機能インフラストラクチャを使用して、テスト セッションに関係するコンポーネント間で機能を通信するための強力なメカニズムを実現する方法を示します。 このサンプルでは、テスト フレームワーク用に特別に設計された機能を示していますが、どのコンポーネントでも、 ICapabilityから継承する拡張機能を公開して実装できます。
インターフェイスを介してすべての詳細を伝達できるわけではないのは明らかです。 前の例を考えると、 CanProvidePerTestCpuConsumption がサポートされている場合、拡張機能は何を期待する必要がありますか? テスト フレームワークによって IMessageBus を介して送信されるカスタム情報の種類は何ですか? このソリューションは、 この機能のドキュメントです。 特定の機能を必要とする拡張機能と効果的に共同作業を行う実装者を支援するために、可能な限り明確に設計、出荷、文書化するのは、機能所有者の責任です。
たとえば、TRX レポート拡張機能を使用すると、TRX レポートを正確に生成するために必要な機能をテスト フレームワークで実装できます。 登録する拡張機能は https://www.nuget.org/packages/Microsoft.Testing.Extensions.TrxReport NuGet パッケージに含まれていますが、実装する機能は コントラクト専用パッケージにあります。
結論として、機能システムの主な側面をまとめてみましょう。
- コンポーネント間の明確で安定した通信を促進するために不可欠です。
- すべての機能は、
ICapabilityまたはそれを継承するインターフェイスから継承する必要があり、ICapabilitiesインターフェイスを持つコレクションを介して公開されます。 - これは、破壊的変更を引き起こすことなく、特徴の進化に役立ちます。 特定の機能がサポートされていない場合は、適切なアクションを実行できます。
- 機能の使用方法を設計、出荷、文書化する責任は、機能 所有者にあります。 MTP は、他の拡張機能と同じ方法で機能を 所有 することもできます。
フレームワークの機能
プラットフォームは、テスト フレームワーク用に公開されるすべての機能のベースである ITestFrameworkCapability という名前の特殊なインターフェイスを公開します。 これらの機能は、 テスト フレームワークをプラットフォームに登録するときに提供されます。
IBannerMessageOwnerCapability
オプションの テスト フレームワーク機能により、 テスト フレームワークはバナー メッセージをプラットフォームに提供できます。 メッセージが null されている場合、または機能が存在しない場合、プラットフォームは既定のバナー メッセージを使用します。
この機能の実装により、バナー メッセージを表示するかどうかを決定するときにテスト フレームワークが考慮する必要があるさまざまな条件を抽象化できます。
プラットフォームは、カスタム バナー メッセージを作成するときに役立つ可能性のあるプラットフォームに関する情報を提供するために、 IPlatformInformation サービス を公開します。
.NET