compare-test-case

テストケースの比較

クイックスタート

通常は、テストケースの識別子と2つのブランチを受け取ります。次の手順に従ってください。

1. tuist test case show <id-or-identifier> --json を実行して、テストケースのメトリクスを取得します。
2. tuist test case run list <identifier> --json を実行して、ブランチごとの実行を確認します。
3. ベースブランチとヘッドブランチの動作を比較します。
4. tuist test case run show <run-id> --json を実行して、失敗を調査します。
5. 根本原因の分析を含めて、調査結果をまとめます。

ステップ1：テストケースを特定する

IDまたはダッシュボードのURLから

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

識別子（Module/Suite/TestCase）から

tuist test case show Module/Suite/TestCase --json

テストケースが指定されていない場合

調査対象となる不安定なテストまたは失敗するテストを検出します。

tuist test case list --flaky --json --page-size 10

レスポンスの主なフィールド：

• id -- 後続のコマンドで使用する一意の識別子
• name、module_name、suite_name -- テストの識別情報
• reliability_rate -- 成功した実行の割合
• flakiness_rate -- 過去30日間における不安定な実行の割合
• total_runs / failed_runs -- 実行数の参考情報
• is_flaky / is_quarantined -- 現在のフラグ

ステップ2：各ブランチの実行を取得する

テストケースで絞り込んで実行を一覧表示し、git_branch フィールドを確認します。

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

ブランチごとに実行を分けます。各ブランチについて、次の値を計算します。

• 成功率：passed_runs / total_runs * 100
• 平均実行時間
• 不安定な実行の数
• 最新のステータス

デフォルト

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

ステップ3：ブランチ間の動作を比較する

メトリクス	ベースブランチ	ヘッドブランチ	判定
成功率	例：100%	例：60%	REGRESSION
平均実行時間	例：0.5s	例：2.1s	REGRESSION
不安定な実行	0	3	NEW FLAKINESS
最終ステータス	success	failure	REGRESSION

変更を分類します。

• 新たに失敗：ベースの成功率が100%で、ヘッドが100%未満
• 新たに不安定：ベースに不安定な実行がなく、ヘッドに不安定な実行がある
• 実行時間のリグレッション：平均実行時間が50%を超えて増加
• 修正済み：ベースでは失敗し、ヘッドでは成功
• 安定：両方のブランチで動作が同じ

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

ヘッドブランチで失敗した実行ごとに、次を実行します。

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

次の項目を確認します。

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

ステップ5：根本原因を特定する

比較結果に基づいて、次のように調査します。

新たに失敗

• ベースブランチとヘッドブランチ間のコミットを確認し、テストファイルまたはテスト対象のコードに変更がないか調べます。
• 失敗メッセージから、何が変わったのか手がかりを探します。

新たに不安定

• よくあるパターン：タイミングや非同期処理の問題、共有状態、環境への依存。
• repetitions に断続的な成功・失敗のパターンが示されているか確認します。
• 不安定なテストを詳細に分析する方法については、fix-flaky-tests スキルを参照してください。

実行時間のリグレッション

• セットアップやティアダウンの時間が増加していないか確認します。
• テストの処理量が増えていないか（新しいアサーションや大きなデータセットなど）確認します。
• 依存関係の処理が遅くなっていないか確認します。

まとめの形式

次の項目を含めてまとめます。

1. テストケース情報：名前、モジュール、スイート、全体的な信頼性。
2. ベースブランチの動作：成功率、平均実行時間、不安定な実行数。
3. ヘッドブランチの動作：成功率、平均実行時間、不安定な実行数。
4. 判定：変更内容と分類。
5. 根本原因：失敗分析に基づく仮説。
6. 推奨事項：具体的なファイルパス、行番号、修正案。

例：

Test Case Comparison: AuthModuleTests/LoginTests/test_login_with_expired_token

Overall reliability: 85% (was 100% before head branch)

Base (main):
  Pass rate: 100% (15/15 runs)
  Avg duration: 0.3s
  Flaky: No

Head (feature/auth-refactor):
  Pass rate: 60% (3/5 runs)
  Avg duration: 0.5s
  Flaky: Yes (2 flaky runs)

Verdict: NEWLY FLAKY -- test was stable on main but intermittently fails on feature branch

Root cause: The auth refactor introduced an async token refresh that races with the
test's synchronous assertion. Failures show "Expected status 401, got nil" at
Tests/AuthModuleTests/LoginTests.swift:42, suggesting the response arrives before
the token refresh completes.

Recommendations:
- Add an await/expectation before the assertion at LoginTests.swift:42
- Consider mocking the token refresh to make the test deterministic

完了チェックリスト

• テストケースの識別情報を特定した
• 両方のブランチの実行を収集した
• 成功率、実行時間、不安定さを比較した
• 失敗した実行の詳細を調査した
• ファイルパスと行番号を含めて根本原因を特定した
• 実行可能な修正案を提示した