compare-test-runs

テスト実行を比較する

クイックスタート

通常、2 つのテスト実行 ID が渡されます。以下の手順に従ってください。

1. ベースとヘッドの両方のテスト実行に対して、tuist test show <id> --json を実行します。
2. tuist test module list <test-run-id> --json と tuist test suite list <test-run-id> --json を実行して、モジュールとテストスイートの内訳を取得します。
3. tuist test case run list <identifier> --json を実行して、個々のテストケースの結果を取得します。
4. 失敗、不安定なテスト、所要時間、全体のステータスを比較します。
5. 失敗したテストケースを tuist test case run show <id> --json で調査します。
6. 実行可能な推奨事項を添えて調査結果をまとめます。

ステップ 1：テスト実行を特定する

base/head がテスト実行 ID またはダッシュボード URL の場合

それぞれを直接取得します。

tuist test show <base-id> --json
tuist test show <head-id> --json

base/head がブランチ名の場合

各ブランチの最近のテスト実行を一覧表示し、テスト実行 ID を特定します。

tuist test list --git-branch <base-branch> --json --page-size 5
tuist test list --git-branch <head-branch> --json --page-size 5

各ブランチの結果から最新のテスト実行 ID を選びます。

デフォルト

• base が指定されていない場合は、プロジェクトのデフォルトブランチ（通常は main）を使用します。
• head が指定されていない場合は、現在の Git ブランチを検出します。

ステップ 2：トップレベルの指標を比較する

両方のテスト実行を取得した後、以下を比較します。

指標	確認する内容
status	base が成功し、head が失敗した場合にフラグを立てます
duration	head が 10% を超えて遅い場合にフラグを立てます
total_test_count	テスト数の変更（新規テストまたは削除されたテスト）を記録します
failed_test_count	失敗数を比較します
flaky_test_count	不安定なテストの数を比較します
avg_test_duration	大幅な変更があればフラグを立てます

ステップ 3：モジュールとテストスイートの内訳を取得する

両方のテスト実行についてモジュールとテストスイートレベルの結果を取得し、どの領域でリグレッションが発生したかを確認します。

tuist test module list <base-test-run-id> --json
tuist test module list <head-test-run-id> --json

tuist test suite list <base-test-run-id> --json
tuist test suite list <head-test-run-id> --json

両方の実行でモジュールとテストスイートを名前で照合し、新たな失敗や所要時間のリグレッションが発生した領域を特定します。

ステップ 4：個々のテストケースの結果を取得する

両方のテスト実行について、テストケースの実行結果を取得します。

tuist test case run list <identifier> --json --page-size 100

両方の実行で、テストケースを name + module_name + suite_name で照合します。

ステップ 5：変更を分類する

テストケースを以下のカテゴリに分類します。

1. 新たな失敗：base では成功し、head では失敗したテストです。
2. 修正されたテスト：base では失敗し、head では成功したテストです。
3. 新たに不安定になったテスト：base では不安定でなく、head では不安定になったテストです。
4. 不安定でなくなったテスト：base では不安定で、head では安定したテストです。
5. 新規テスト：base にはなく、head にあるテストです。
6. 削除されたテスト：base にあり、head にはないテストです。
7. 所要時間のリグレッション：所要時間が 50% を超えて増加したテストです。

ステップ 6：失敗を調査する

新たに失敗したテストごとに、詳細情報を取得します。

tuist test case run show <test-case-run-id> --json

確認する主なフィールド：

• failures[].message -- アサーションまたはエラーメッセージ
• failures[].path -- ソースファイルのパス
• failures[].line_number -- 失敗した正確な行
• failures[].issue_type -- 問題の種類
• repetitions -- 存在する場合は、再試行の動作（不安定さの検出）を示します
• crash_report -- テストランナーがクラッシュした場合のクラッシュデータ

ステップ 7：添付ファイルを調査する

tuist test case run show の出力には、添付ファイルとクラッシュレポートの情報が含まれます。以下を確認します。

• スクリーンショットまたは UI テストの成果物
• ログファイルまたはクラッシュレポート
• 失敗した実行に添付された診断データ

まとめの形式

以下を含むまとめを作成します。

1. 全体的な評価：base と比べて改善、悪化、または変化なし。
2. 新たな失敗：失敗メッセージ、ファイルパス、行番号とともにそれぞれ記載します。
3. 新たに不安定になったテスト：不安定さの状況とともに記載します。
4. 修正されたテスト：現在は成功しているテストを記載します。
5. 所要時間：全体の所要時間と、特に目立つテストごとのリグレッション。
6. 推奨事項：各問題に対する実行可能な次のステップ。

例：

Test Run Comparison: base (run-123 on main) vs head (run-456 on feature-x)

Status: success -> failure -- REGRESSION
Duration: 120.5s -> 145.2s (+21%)
Tests: 342 -> 345 (3 new tests)
Failures: 0 -> 2 (2 new failures)
Flaky: 1 -> 3 (2 newly flaky)

New Failures:
1. AuthModuleTests/LoginTests/test_login_with_expired_token
   Message: "Expected status 401, got 500"
   File: Tests/AuthModuleTests/LoginTests.swift:42
   Likely cause: Server error handling changed for expired tokens

2. NetworkTests/RetryTests/test_retry_on_timeout
   Message: "Timed out waiting for retry"
   File: Tests/NetworkTests/RetryTests.swift:87
   Likely cause: Timeout threshold too low after network layer refactor

Newly Flaky:
1. CacheTests/WriteCacheTests/test_concurrent_writes (flaky in 3/5 runs)

Recommendations:
- Fix expired token handling in AuthModule
- Increase timeout in RetryTests or mock the network layer
- Investigate concurrent write synchronization in CacheTests

完了チェックリスト

• base と head の両方のテスト実行を特定した
• トップレベルの指標を比較した
• 両方の実行についてモジュールとテストスイートの内訳を取得した
• 新たな失敗、修正されたテスト、不安定さの変化を特定した
• 新たな失敗について詳細を調査した
• ファイルパスを示した、実行可能な推奨事項を提示した