テスト影響分析 (TIA) を使用してテストを高速化する

[アーティクル]
04/05/2024

Azure DevOps Services | Azure DevOps Server 2022 - Azure DevOps Server 2019

継続的インテグレーション (CI) は、業界の重要なプラクティスです。統合は頻繁に行われ、統合エラーをできるだけ早く検出するために回帰テストを実行する自動ビルドで検証されます。ただし、コードベースが大きくなり成熟するにつれて、回帰テストスイートも拡大する傾向があります。そのため、完全な回帰テストに数時間かかることもあります。これにより、統合の頻度が遅くなり、最終的には継続的インテグレーションの目的を果たさなくなります。 CI パイプラインを迅速に完了させるために、チームによっては、実行時間の長いテストの実行をパイプライン内の別のステージに先送りすることがあります。ただし、これでは継続的インテグレーションの意図に反してしまいます。

代わりに、ビルドパイプラインで Visual Studio テストタスクを使用するときに、テスト影響分析 (TIA) を有効にします。 TIA では、自動テスト選択によって増分検証を実行します。コミットされるコードを検証するために必要なテストのサブセットのみが自動的に選択されます。 CI/CD パイプラインに入る特定のコードコミットに対して、TIA はコミットの検証に必要な関連テストのみを選んで実行します。したがって、テスト実行はより迅速に完了し、エラーが発生しても早期に把握できます。また、関連性によってすべてスコープが設定されているため、分析も迅速に行えます。

TIA を使用する場合のテスト時間の比較

テスト影響分析 (TIA) には、次のような特徴があります。

堅牢なテスト選択メカニズム。影響を受ける既存のテスト、以前に失敗したテスト、新しく追加されたテストが含まれます。
安全なフォールバック。 TIA で理解できないコミットとシナリオの場合、すべてのテストを実行するようフォールバックします。現在、TIA のスコープはマネージドコードと単一マシントポロジのみです。そのため、たとえばコードコミットに HTML ファイルまたは CSS ファイルへの変更が含まれている場合、それらのファイルについて論理的に検証することはできないため、すべてのテストを実行するようフォールバックします。
構成可能なオーバーライド。すべてのテストは、構成された周期で実行できます。

ただし、Visual Studio 2015 で TIA を使用する場合は、次の点に注意してください。

テストを並列で実行する場合。テストは順次実行されます。
コードカバレッジを有効にしたテストの実行の場合。コードカバレッジデータは収集されません。

テスト影響分析でサポートされているシナリオ

現時点では、TIA では次のシナリオがサポートされています。

TFS 2017 Update 1 以降と Azure Pipelines
ビルドパイプラインの Visual Studio テストタスクのバージョン 2.*
複数の VSTest タスクを使用して vNext をビルドする
ビルドエージェントでの VS2015 Update 3 以降
ローカルおよびホステッドビルドエージェント
CI および PR ワークフロー
Git、GitHub、その他の Git、TFVC リポジトリ (部分的にマップされた TFVC リポジトリと回避策を含む)
HTTP/HTTPS プロトコルを使用した IIS 操作 (REST、SOAP API 経由)
自動テスト
単一マシントポロジ。テストとアプリ (SUT) は、同じマシンで実行されている必要があります。
マネージドコード (任意の.NET Framework アプリ、任意の .NET サービス)

現時点では、次のものに対して TIA はサポートされていません。

複数マシントポロジ (テストで別のマシンにデプロイされたアプリを実行する場合)
データドリブンテスト
テストアダプター固有の並列テスト実行
.NET Core
UWP

TIA スコープとアプリケーションの詳細

テスト影響分析を有効にする

TIA は、Visual Studio テストタスクのバージョン 2.* でサポートされています。アプリが単一層アプリケーションの場合は、タスク UI で [影響を受けたテストのみを実行する] をチェックするだけです。テストインパクトデータコレクターは自動的に構成されます。追加の手順は必要ありません。

VS Test タスク UI で TIA を有効にする

アプリケーションが IIS のコンテキストでサービスと対話する場合は、.runsettings ファイルを使用して IIS のコンテキストでも実行するようにテストインパクトデータコレクターを構成する必要があります。この構成を作成するサンプルを次に示します。

<?xml version="1.0" encoding="utf-8"?>
<RunSettings>
  <DataCollectionRunSettings>
    <DataCollectors>
      <!-- This is the TestImpact data collector.-->
      <DataCollector uri="datacollector://microsoft/TestImpact/1.0" assemblyQualifiedName="Microsoft.VisualStudio.TraceCollector.TestImpactDataCollector, Microsoft.VisualStudio.TraceCollector, Version=15.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" friendlyName="Test Impact">
        <Configuration>
          <!-- enable IIS data collection-->
          <InstrumentIIS>True</InstrumentIIS>
          <!-- file level data collection -->
          <ImpactLevel>file</ImpactLevel>
          <!-- any job agent related executable or any other service that the test is using needs to be profiled. -->
          <ServicesToInstrument>
            <Name>TeamFoundationSshService</Name>
          </ServicesToInstrument>
        </Configuration>
      </DataCollector>
    </DataCollectors>
  </DataCollectionRunSettings>
</RunSettings>

テスト影響分析の結果を表示する

TIA は、通知メールを含め、概要レベルと詳細レベルの両方で既存のテストレポートに統合されています。

レポートの概要に TIA 統合が含まれる

レポートのテストページに TIA 統合が含まれる

TIA と Azure Pipelines の統合の詳細

テスト影響分析の動作を管理する

テスト実行中にテストを含めるか無視する方法に影響を与えることができます。

VSTest タスク UI を使用する。 TIA では、構成された周期ですべてのテストを実行するように条件を設定できます。このオプションを設定することをお勧めします。これは、テストの選択を規制する手段です。
ビルド変数を設定する。 VSTest タスクで TIA を有効にした後でも、変数 DisableTestImpactAnalysis を true に設定することで、特定のビルドに対して無効にすることができます。このオーバーライドにより、TIA ではそのビルドのすべてのテストを強制的に実行します。以降のビルドでは、TIA では最適化されたテスト選択に戻ります。

TIA でコミットを開いたときに不明なファイルの種類があると、すべてのテストを実行するようフォールバックします。これは安全の観点からは良いことですが、場合によってはこの動作のチューニングが有益な場合があります。次に例を示します。

TI_IncludePathFilters 変数を特定のパスに設定して、TIA で適用するリポジトリにこれらのパスのみを含めることができます。これは、チームで共有リポジトリを使用する場合に便利です。この変数を設定すると、設定に含まれていない他のすべてのパスに対して TIA が無効になります。
TIA_IncludePathFilters 変数を設定して、テストの結果に影響を与えない、かつ変更を無視する必要があるファイルの種類を指定します。たとえば、.csproj ファイルへの変更を無視するには、変数に !**\*.csproj の値を設定します。

変数を設定するときに minimatch パターンを使用し、複数の項目をセミコロンで区切ります。

TIA が適切なテストを選択しているかどうかを評価するには、次を実行します。

選択内容を手動で検証します。 SUT とテストがどのように設計されているか知っている開発者であれば、TIA レポート機能を使用してテストの選択を手動で検証できます。
TIA で選択したテストを実行し、すべてのテストを順番に実行します。ビルドパイプラインでは 2 つのテストタスクが使用されます。1 つは、影響を受けるテストのみを実行し (T1)、もう 1 つはすべてのテストを実行します (T2)。 T1 が合格した場合は、T2 も合格します。 T1 で失敗したテストがあった場合は、T2 で同じエラーが報告されているかどうかを確認します。

TIA の高度な構成に関する詳細

カスタム依存関係マッピングを提供する

TIA では、次の形式の依存関係マップが使用されます。

TestMethod1
  dependency1
  dependency2
TestMethod2
  dependency1
  dependency3

TIA では、マネージドコード実行用の依存関係マップを生成できます。このような依存関係が .cs ファイルや .vb ファイルに存在する場合、TIA では自動的にこれらのファイルへのコミットを監視し、依存関係の一覧にこれらのソースファイルが含まれていたテストを実行できます。

依存関係マップを XML ファイルとして明示的に指定することで、TIA のスコープを拡張できます。たとえば、JavaScript や C++ などの他の言語のコードや、テストと製品コードが異なるマシンで実行されているシナリオをサポートできます。マッピングは近似的なものでもかまいません。また、通常は VSTest タスクパラメーターで指定されるようなテストケースフィルターの観点から、実行するテストのセットを指定できます。

XML ファイルは、リポジトリ (通常はルートレベル) にチェックインする必要があります。次に、ビルド変数 TIA.UserMapFile をポイントするように設定します。たとえば、ファイル名が TIAmap.xml の場合は、変数を $(System.DefaultWorkingDirectory)/TIAmap.xml に設定します。

XML ファイル形式の例については、TIA カスタム依存関係マッピングに関するページを参照してください。

参照

ヘルプとサポート

トラブルシューティングページを参照してください。
Stack Overflow に関するアドバイスを受け取り、Developer Community を介してサポートを受ける