並列テスト
並列テスト ビルド機能は、テストスイートを複数のバッチに分割し、各バッチを個別のビルドエージェントに割り当て、すべてを並列で実行します。ダミー削除予定? テストスイートが大きく、構成するバッチ数が多いほど、このパフォーマンス向上はより大きく、より明確に実感できます。
Maven、 Gradle、 IntelliJ IDEA プロジェクト、 .NET のビルドステップでは、この機能を追加して必要なバッチ数を選択する以外に何もする必要はありません。 TeamCity はテストのフィルタリングを自動的に処理します。
その他のランナーでは、追加のセットアップが必要です。 詳細については、 並列化されたテストのカスタム実行 セクションとナレッジベース記事 任意のビルドランナーで Parallel Tests ビルド機能を使用する を参照してください。
テストを並列実行
並列テストビルド機能は、異なるエージェント上での並列テスト実行のタスクを解決します。
既存のビルド構成でこの機能を有効にするには:
構成設定 を開き、 ビルド機能 設定タブに移動します。
ビルド機能を追加 をクリックし、 並列テストタイプを選択します。
テストバッチ数を設定します。これは、ビルドで使用する並列エージェント数も意味します。
TeamCity がテストを並列実行するためにバッチに分割する前に、少なくとも 1 つ前のビルドのテスト統計を収集する必要があります。 この情報により、合計ビルド時間ができるだけ短くなるように、テストを (テスト時間に基づいて) ほぼ同じサイズのバッチに細分化できます。 新しく追加されたビルド構成でこの機能を有効にした場合、最初のビルドは通常モードで実行されます。完了してテストレポートが生成されると、TeamCity は 2 回目のビルドを分割できるようになります。
TeamCity は、最新のテスト実行だけでなくテストの履歴も考慮します。並列テストを含む次回以降のビルドもこの統計に寄与し、TeamCity がよりスマートな判断を行えるようにします。
内部の仕組み
テスト統計が利用可能な場合、新しいビルドがトリガーされると次のようになります。
TeamCity は、ビルド機能で指定されたバッチ数に従って、現在のビルド構成のコピーを生成します。 これらのビルド構成は、元の構成と同じビルドステップになります。 将来的には、元の構成のビルドステップへの変更は、生成されたものに自動的に反映されます。
トリガーされたビルドは、生成されたビルド構成からのビルドに依存する 複合ビルドに変換されます。
最初の依存関係ビルドが開始されるとすぐに、複合ビルドも開始されます。
生成されたビルド構成のビルドは、元のビルド構成で定義されたものと同じ一連のビルドステップを実行します。 これらのステップの一部が Maven、 Gradle、 IntelliJ IDEA Project 、または .NET タイプで、何らかのテストを実行していた場合、これらのビルドランナーは現在のバッチに対応するテストの部分のみを自動的に実行します。
テストを別の方法で実行する場合でも、構成で 並列テスト ビルド機能を有効化し、自動テスト分割を利用できます: 実行するテストに関する情報は、ビルド機能によって提供される ビルドパラメーター から取得できます。
ランナー固有の要件
テストのセット全体ではなく、テストのバッチの自動実行は、次の要件が満たされている場合にのみサポートされます。
並列化されたテストのカスタム実行
一部のワークフローでは、TeamCity がテスト実行を制御しないため、テストをバッチに分割できません。 例: テストが動的に生成される場合、カスタムビルドステップによって報告される場合、またはファイルからインポートされる場合。
それでも、TeamCity は実行済みテストを追跡し、過去の実行を分析して最適なバッチ配分を計算します。 このデータは、以下のパラメーターで取得できます。
teamcity.build.parallelTests.currentBatch— 現在のバッチ番号（1 から始まる）。teamcity.build.parallelTests.totalBatches— バッチの合計数。system.teamcity.build.parallelTests.excludesFile—currentBatchの実行時に無効にするテストに関する情報を保存するexcludesFile.txtファイルへのエージェントマシン上のパス。
テストを並列に実行するには、これらのパラメーターを読み取り、現在のバッチに属さないテストを無効にするカスタムメカニズム (テストフレームワーク拡張機能やビルドステップなど) を実装します。
除外ファイル ファイルは TeamCity サーバーによって生成されるため、手動で変更しないでください。 このファイルの形式は次のとおりです。
- バージョン
ファイル形式のバージョンを表す整数値です。 カスタムテスト実行ロジックがバージョンを確認し、バージョンが予期しない値の場合はエラーを報告するかビルドを失敗させることを想定しています。
- アルゴリズム
テストをバッチに分割する役割を持つアルゴリズムのタイプです。 利用可能な値:
期間— ほぼ同じ実行時間のバッチを作成するため、主要なメトリクスとしてテストクラスの実行時間を優先します。スイートを分割— テストスイート内の各テストクラスを N 個のバッチに分割します。スイートをグループ化—期間と同じですが、個々のテストクラスは無視し、同じスイートのすべてのテストを 1 つのバッチにグループ化します。
- current_batch
現在のバッチ番号で、
teamcity.build.parallelTests.currentBatchパラメーター と同じです。- total_batches
バッチの合計数で、
teamcity.build.parallelTests.totalBatchesパラメーター と同じです。- suite
テストスイート名です。 このパラメーターは空の場合があります。 バッチに複数の suite からのテストが含まれる場合、各 suite は別々の行に一覧表示されます。
注: Java および .NET テストフレームワークは通常、次の形式で TeamCity にテストを報告します:
[<suite お名前>: ]<完全修飾テストクラスお名前>.<テストメソッド>[<テスト引数>]
<suite お名前> および <テスト引数> はオプションであり、常に存在するとは限りません。
例: 次の Java テストクラス:
TeamCity で次のテスト名が生成されます:
次に、パラメーター system.teamcity.build.parallelTests.excludesFile は、次の内容のテキストファイルを指します。
.NET の代替テストフィルタリング
.NET ランナーが大量のテストクラスを処理する場合、並列テストにより、NUnit などのテストエンジンで解析して使用するのが難しい巨大なテストフィルターが生成される可能性があります。
潜在的なパフォーマンスの問題を回避するため、TeamCity はこれらのケースに最適化された代替テストフィルタリングモードを自動的に使用します。 このモードは、次の条件が満たされる場合、エージェントごとに有効になります。
テストバッチを実行するエージェントは、.NET CLI (SDK またはランタイム) 6.0 以降を報告します。
テストバッチには 1000 以上のテストクラスが含まれます。 このしきい値は、
teamcity.internal.dotnet.test.suppression.test.classes.しきい値構成パラメーターを介して変更できます。
TeamCity がこのモードに切り替わらないようにし、個々のプロジェクトまたはビルド構成で通常のフィルタリングメカニズムを使用して並列 .NET テストを常に実行するよう強制できます。 これを行うには、 teamcity.internal.dotnet.test.suppression=false パラメーターを必要な構成またはプロジェクトに追加します。
バッチビルドで生成されたアーティファクトを公開
並列テストは独立したバッチビルド内で実行されるため、 アーティファクトは親構成のビルドではなく、実際のビルドルーチンを実行するこれらのバッチビルドによって生成されます。 簡単にアクセスできるように、TeamCity は個々のバッチのアーティファクトをメイン構成ビルドに集約します。
バッチビルドによって同一のアーティファクトが生成される場合、親構成の アーティファクトタブには最新のバッチビルドのアーティファクトのみが表示されます。
これらのファイルがすべて関連しており、メインビルドから表示する必要がある場合は、並列テスト機能の アーティファクト 設定を有効にします。
これにより、TeamCity はメイン構成ビルドでバッチ出力を集約するときに、"batchN" フォルダーに配置できるようになります。
アーティファクトパスに パラメーターを追加することで、カスタムグループ化ロジックを実装できます。 パラメーターはバッチごとに一意の値を持つ必要があります。 例: teamcity.build.parallelTests.currentBatch パラメーターを追加すると、前述の並列テスト機能の設定と同様の結果が生成されます。
アップストリームチェーンビルドでの並列テスト
常に新しいビルドを実行 の動作 (スナップショット依存関係 の 適切なものがあれば、新しいビルドを実行しないでください 設定が無効) は、メイン構成ビルドにのみ影響します。 並列テスト 機能の使用時に動的に生成される仮想ビルド構成は、以前の結果を引き続き再利用する場合があります。 新しいリポジトリコミットが検出されなかった場合、以前に失敗したテストバッチのみが新しいビルドを実行し、成功したバッチは再利用されます。
下の図では、「Composite Conf」構成は「Maven App」構成に依存しています。 後者は、2 つの並列バッチでテストを実行します。 メインの「Maven app」ビルド #18 は新たにトリガーされますが、動的に生成された「Maven app 1」構成は、以前の成功したビルド (#12) を再利用することに注意してください。
TeamCity にすべての仮想構成ビルドを強制的に再実行させることができます。 この場合、新しいリポジトリコミットが見つからなくても、個々のテストバッチはすべて新たに実行されます。
これを行うには、並列テスト機能がある構成に teamcity.internal.splitBuild.dependency.takeStartedBuildWithSameRevisions=false パラメーター を追加します。
この動作をサーバー上のすべての構成に適用するには、このパラメーターを 内部プロパティリストに追加します。
既知の制限
コードカバレッジ統計は、現在のバッチによって実行されたテストの一部に対して収集されるため、並列テストを使用したビルドでは不正確になります。
TeamCity にまだ認識されていない新しく追加されたテストは、初回実行時に各バッチで実行されます。 関連する YouTrack チケット: TW-75913(英語)。
TeamCity がテストをバッチに分割する際、考慮するのはテスト自体の所要時間だけです。 setUp/tearDown やその他の準備メソッドの所要時間は TeamCity に認識されないため、バッチの所要時間が等しくならない場合があります。
ビルドはトリガー後に複合ビルドに変換されるため、並列テストを含むビルドのカスタムビルドダイアログで選択されたエージェントは無視されます。 関連する YouTrack チケット: TW-74905(英語)。
setParameter サービスメッセージを介してビルドステップによって公開されたパラメーター、および
Maven プロジェクトのバージョンなどのランナー固有のパラメーターは、並列テストを含む複合ビルドでは使用できません。 関連する YouTrack チケット: TW-75249(英語)。TeamCity Professional バージョンのビルド構成数の制限に関しては、自動的に生成されたビルド構成は通常のビルド構成としてカウントされます。
既知のバグ
クリーンチェックアウトアクションを実施するは、並列テストが構成されたビルド構成では機能しません。 関連する YouTrack チケット: TW-75337(英語)。
Gradle では、 XML スイート(英語)から TestNG(英語) テストを実行するために生成されたバッチビルドが、指定されたテストのサブセットではなく、すべてのテストを実行します。 関連する YouTrack チケット: TW-75849(英語)。
Maven と TestNG(英語) の組み合わせでは、 XML スイート(英語)ファイルは無視されます。 関連する YouTrack チケット: TW-95644(英語)。