mcpField
C
ci-fix-tests

ci-fix-tests

github.com/codeceptjs测试与质量2104 次安装1 周前更新
代码仓库

关于 ci-fix-tests

ci-fix-tests 是用于在 CI 中修复失败 CodeceptJS 测试的保守型技能。它仅处理特定定位器和等待问题，只重跑失败场景，撤销无效修改并生成机器可读报告。

主要功能

  1. 01读取失败追踪并记录基线
  2. 02处理定位器漂移与缺失等待
  3. 03仅修改失败测试文件
  4. 04只重跑原先失败的场景
  5. 05撤销无效修改
  6. 06生成 CI 修复报告

适用场景

  1. 01修复 CI 测试中过时的定位器
  2. 02为延迟出现的元素添加定向等待
  3. 03检查小幅测试修改是否减少失败
  4. 04报告尚未解决的 CI 测试失败

安装

复制下面的命令，在终端中运行。

$npx skills add https://github.com/codeceptjs/skills --skill ci-fix-tests

安装后在 Claude Code 中输入/ci-fix-tests确认已加载。

详细介绍

在 CI 上自动修复 CodeceptJS 测试

一个非交互式自动修复循环。从 output/（aiTrace 在此留下了跟踪产物）读取失败测试基线，尝试少量安全修复，仅重新运行失败的场景，进行对比，并在 output/ci-fix.md 中生成报告。回滚任何无效的修改。

设计上保持保守。 CI 不是重构测试、修改抽象或修复任何需要人工判断的问题的地方。目标是“让本次运行通过”。风险较高的事项会通过报告升级处理。

此技能假定 git 检出正常工作——回滚时会使用 git checkout -- <file> 还原原始内容。

工作流

1. 读取基线失败项

使用 codeceptjs-run-analysis 技能分析现有的 output/trace_*/ 产物，列出所有失败场景。记录：

  • 失败测试的集合（文件路径 + 场景名称）
  • 每项测试中失败的步骤，以及涉及的定位器 / 等待 / 断言
  • 每项失败的集群特征（以便明确区分个别问题与系统性问题）

将此保存为基线——count、failing_set、clusters。

2. 选择安全的修复候选项

只尝试以下允许列表中的修复：

  • 定位器偏移 — 失败的定位器已无法匹配任何内容，但存在相似元素。使用 codeceptjs-exploration 技能（无头模式）查找候选项；选择一个限定在稳定区域内的简短定位器——I.click('Save', '.toolbar')——优先顺序为：可见文本 / 无障碍名称 → ARIA { role, name } → $name（customLocator）→ 组合 CSS。仅替换失败步骤中的定位器。
  • 缺少对微调器 / 加载器 / 模态框的等待 — 失败步骤的 ARIA 快照显示存在微调器或骨架屏，或者目标元素稍后才出现。在失败步骤之前立即添加一个对应的 I.waitFor*。
  • 替换 I.wait(N) — 当硬编码等待是失败断言与通过断言之间的唯一差异，且能够识别控制条件的元素时，将等待替换为特定的 waitFor*。

不要尝试：

  • 修复身份验证 / 凭据 / 环境变量——这些属于 CI 配置，而非测试代码。
  • 重构（提取页面对象、自定义辅助函数、拆分场景）。
  • 重命名场景或标签——CI 的 --grep 和流水线会引用它们。
  • 向场景添加 retries: N——是否掩盖不稳定问题应由人工决定。
  • 修改失败测试文件之外的任何内容（不得修改 codecept.conf.*、辅助函数或 PO）。

如果某项失败不符合任何允许的修复模式，跳过它，并在报告中将其记录为 unresolved。

3. 应用修改并重新运行

跟踪每项修改：文件路径、行号、修改前后的代码片段、修复类型。然后在 CI 使用的相同配置下，仅重新运行失败的场景：

npx codeceptjs run --grep '<scenario>|<scenario>|...'

通过 package.json 脚本或 CI 工作流文件找到正确的配置。如果原先使用了 run-workers，则保持相同的 worker 数量。

4. 与基线进行对比

再次使用 codeceptjs-run-analysis 技能，列出修复后的失败测试集合。

新失败集合与基线的关系状态
空（零失败）SUCCESS_FULL
基线的严格子集SUCCESS_PARTIAL
集合完全相同NO_IMPROVEMENT
集合更大，或包含基线中不存在的测试REGRESSED
5. 决定：保留还是回滚
  • SUCCESS_FULL / SUCCESS_PARTIAL → 保留修改。
  • NO_IMPROVEMENT / REGRESSED → 使用 git checkout -- <files> 回滚所有修改。技能结束时，磁盘上的状态必须与开始时完全一致。

回归与未改善同样处理——这次尝试无效，工作状态应恢复为修改前磁盘上的状态。不要尝试“只撤销有问题的修改”——整个批次都要回滚。

6. 编写报告（始终执行）

无论结果如何，都要编写 output/ci-fix.md——CI 会读取此文件以展示结果。

报告格式

# CI Fix Report — <ISO timestamp>

**Status:** SUCCESS_FULL | SUCCESS_PARTIAL | NO_IMPROVEMENT | REGRESSED

## Baseline
Failing scenarios: N
- `tests/foo_test.js` — "user can log in"
- `tests/bar_test.js` — "checkout flow"
- ...

## Attempted fixes
- `tests/foo_test.js:42` — locator drift: `I.click('Save')` → `I.click('Save', '.toolbar')`
- `tests/bar_test.js:15` — added `I.waitForInvisible('.spinner')` before checkout click
- `tests/baz_test.js:7` — replaced `I.wait(3)` with `I.waitForVisible('.confirmation-dialog', 10)`

## Result
Failing scenarios after fix: M (was N)
- Resolved: `tests/foo_test.js` — "user can log in"
- Still failing: `tests/bar_test.js` — "checkout flow"
- New failures (REGRESSED only): `tests/baz_test.js` — "edit profile"

## Failure clusters (NO_IMPROVEMENT / REGRESSED only)
- **Cluster A (3 scenarios)** — `Element not found: button.btn-primary`. Likely a deploy regression or design change.
- **Cluster B (1 scenario)** — `Navigation timeout to /checkout`. Possible backend issue.

## Discarded changes (NO_IMPROVEMENT / REGRESSED only)
- `tests/foo_test.js` — restored
- `tests/bar_test.js` — restored
- `tests/baz_test.js` — restored

Status: 的第一行是可供机器解析的信号。其余内容供查看失败 CI 构建的人阅读。

应避免的事项

  • 编辑失败测试文件以外的文件。在此模式下，配置、辅助工具、页面对象和 CI 工作流均不可更改。
  • 在一轮中对同一场景尝试多种修复类型。先修复一处，观察结果，再尝试其他修复。
  • 使用 retries: N 掩盖不稳定性——由人工决定。
  • 遇到 NO_IMPROVEMENT 时跳过回滚。即使是无实际效果的编辑，也可能使下一次运行或下一位审查者困惑。
  • 不要漏写或只写部分 output/ci-fix.md。CI 依赖此文件；缺少报告本身就是一种故障模式。
  • 验证时运行整个测试套件——只运行最初失败的场景，以控制 CI 耗时。

相关技能

  • codeceptjs-run-analysis — 基线、聚类、修复后对比
  • codeceptjs-exploration — 针对漂移的替代定位器
  • codeceptjs-fundamentals — 配置、辅助工具、CI 环境

评论

支持 Markdown