この機能は以前「Intelligent Test Runner」と呼ばれており、一部のタグには依然として「itr」が含まれています。
概要
Test Impact Analysis は、変更されたコードに基づいて、指定されたコミットに関連するテストのみを自動的に選択して実行します。テストカバレッジを維持しながら、テストに費やす時間と CI 全体のコストを大幅に削減します。
Test Impact Analysis は、テストスイートを分析して各テストがカバーしているコードを特定し、そのカバレッジを新しいコード変更によって影響を受けるファイルと照合します。Datadog はこの情報を用いて、関連する影響を受けたテストを選択して実行し、影響を受けないテストを省略することで全体的なテスト期間を短縮します。詳細は仕組みをご覧ください。
Test Impact Analysis は、コミットごとに実行されるテストの数を最小限に抑えることで、パイプラインを混乱させる不安定なテストの発生頻度を低減します。テストの不安定さが、テスト対象のコード変更と無関係な場合、特にイライラさせられることがあります。テストサービスで Test Impact Analysis を有効にすると、各コミットを関連するテストに制限することができ、コード変更に無関係な不安定なテストがビルドを恣意的に破壊してしまうことがなくなります。
すぐに使える構成の制限
デフォルトの構成では、Test Impact Analysis が本来実行されるべきテストをスキップしてしまう可能性があります。特に、以下の変更を自動的に検出することはできません。
- ライブラリの依存関係
- コンパイラオプション
- 外部サービス
- データ駆動型テストにおけるデータファイルの変更
このような場合、Test Impact Analysis はすぐに使える構成では影響を受けるテストをスキップする可能性があります。
テストがスキップされないようにするために使用できる構成メカニズムはいくつかあります。
- リポジトリ内の特定のファイルを追跡ファイルとしてマークすると、これらのファイルが変更されるたびにすべてのテストが実行されます。Dockerfile や Makefile、依存関係ファイル、その他のビルドコンフィギュレーションファイルが追跡ファイルに適しています。
- ソース内の特定のテストをスキップ不可にすることで、常に実行されるように設定できます。これはデータ駆動型のテストや外部システムとやりとりするテストに適しています。詳細はセットアップページをご覧ください。
- リスクの高いコミットを行う際にすべてのテストを実行したい場合は、Git のコミットメッセージのどこかに
ITR:NoSkip (大文字小文字は区別しません) を追加します。 - GitHub をソースコード管理プロバイダーとして使用している場合、プルリクエスト内でテストがスキップされるのを防ぐために、(大文字・小文字を区別せずに)
ITR:NoSkip ラベルを使用してください。この機能を利用するには、GitHub インテグレーションタイルを使って GitHub App を構成し、Software Delivery: Collect Pull Request Information 機能を有効にします。なお、この仕組みは、pull_request イベントによってトリガーされる GitHub Actions 上で実行されるテストには適用されません。 - 除外ブランチのリストを追加して、特定のブランチで Test Impact Analysis を無効にすることができます。
Datadog ライブラリのセットアップ
Test Impact Analysis を設定する前に、特定の言語に対して Test Optimization を構成する必要があります。Agent を通してデータを報告する場合は、v6.40 または 7.40 以降を使用してください。
Datadog で Test Impact Analysis をセットアップする言語を選択します。
構成
Datadog ライブラリを Test Impact Analysis 用に設定したら、Test Service Settings ページから構成します。Test Impact Analysis を有効にするには、Intelligent Test Runner Activation Write 権限が必要です。
Git 実行ファイル
Test Impact Analysis が動作するためには、テストを実行しているホストで Git が利用可能である必要があります。
除外ブランチ
上記の制限により、リポジトリのデフォルトブランチは、自動的に Test Impact Analysis の有効化から除外されます。Datadog は、本番に到達する前にすべてのテストが実行されるようにするために、この構成を推奨します。
他に除外したいブランチがある場合、Test Optimization Settings ページで追加します。クエリバーは、ワイルドカード文字 * の使用をサポートしており、release_* など、一致するブランチを除外することができます。
除外ブランチは、テストごとのコードカバレッジを収集しますが、これは全体のテスト時間に影響を与えます。しかし、Datadog がコードカバレッジを収集することで新しいカバレッジ情報が十分に生成され、そのコストを相殺できると判断した場合にのみコードカバレッジを収集することで、この影響は軽減されます。テストセッションでコードカバレッジが有効かどうかは、@test.code_coverage.enabled フィールドで確認できます。
追跡ファイル
追跡ファイルとは、テストに影響を与える可能性のあるコード以外のファイルのことです。追跡ファイルの変更はテストの失敗やコードカバレッジの変化を引き起こす可能性があります。追跡ファイルとして適している例としては、以下があります。
- CI 環境で使用する Dockerfile
- 依存関係を定義するファイル (例: Maven の
pom.xml、Python の requirements.txt、Javascript の package.json) - Makefile
追跡ファイルのセットを指定すると、Test Impact Analysis はこれらのファイルが変更された場合にすべてのテストを実行します。
すべてのファイルパスはリポジトリのルートからの相対パスとして扱われます。ワイルドカード文字 * と ** を使用して、複数のファイルやディレクトリを指定することができます。例えば、 **/*.mdx はリポジトリ内のすべての .mdx ファイルに一致します。
テストセッションを確認する
テストコミットページやテストセッションパネルを見ることで、Test Impact Analysis で得られる時間短縮を確認することができます。
Test Impact Analysis がアクティブでテストをスキップしている場合、紫色のテキストで、各テストセッションまたは各コミットで節約した時間の量が表示されます。期間バーも紫色に変わるので、Test Runs ページで Test Impact Analysis を使用しているテストセッションを識別できます。
導入とグローバルな節約を確認する
すぐに使える Test Impact Analysis ダッシュボードで、組織の節約と Test Impact Analysis の導入を追跡します。ダッシュボードには、全体の節約を追跡するウィジェットと、リポジトリごと、コミッターごと、サービスごとのデータビューがあります。ダッシュボードを見ることで、組織のどの部分が Test Impact Analysis を使用し、最大限の効果を得ているかを理解することができます。
また、ダッシュボードでは、組織全体における Test Impact Analysis の導入状況を追跡することができます。
その他の参考資料
