compare-test-case

比较测试用例

快速开始

通常你会收到一个测试用例标识符和两个分支。请按以下步骤操作：

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%	回归
平均耗时	例如：0.5s	例如：2.1s	回归
不稳定运行次数	0	3	新增不稳定
最近一次状态	成功	失败	回归

对变化进行分类：

• 新出现的失败：基础分支通过率为 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 技能，了解详细的不稳定测试分析模式。

耗时回归

• 检查 setup/teardown 耗时是否增加。
• 检查测试是否执行了更多工作（新增断言、更大的数据集）。
• 检查依赖项是否变慢。

总结格式

生成总结，包含：

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

完成检查清单

• 已确定测试用例身份
• 已收集两个分支上的运行记录
• 已比较通过率、耗时和不稳定情况
• 已检查失败运行的详细信息
• 已根据文件路径和行号确定根因
• 已提供可执行的修复建议