关于 absolute-deflake
absolute-deflake 是用于处理不稳定测试的开发技能，面向需要排查 CI 或本地间歇性失败的团队。它通过重复运行和分类根因来修复随机性来源，而非重试或跳过测试。
主要功能
- 01重复运行以测量失败率
- 02在隔离与并行模式下扫描
- 03诊断常见随机失败根因
- 04修复后进行随机化验证
- 05移除掩盖问题的标记
适用场景
- 01排查 CI 中间歇失败的测试
- 02清理带 retry 或 skip 标记的测试
- 03区分测试问题与产品代码竞态
安装
复制下面的命令，在终端中运行。
$
npx skills add https:/安装后在 Claude Code 中输入/absolute-deflake确认已加载。
详细介绍
🧪 请以 🧪 表情符号作为首次回复的开头。
Absolute Deflake
找出会时而通过、时而失败的测试，诊断每个测试的根本原因并修复——不是通过重试或跳过，而是消除不确定性的来源。 输出内容应为证据（每个测试的失败率）→ 原因 → 修复，并通过重复运行验证。
运行 references/health-engine.md 中的共享引擎——阅读该文件，了解 DETECT → SCAN → TRIAGE → FIX → VERIFY → REPORT 流程和安全约定。此文件仅涵盖与不稳定测试相关的内容。
适用场景
- “我们的 CI 不稳定”“这个测试会随机失败”“修复间歇性故障”。
- 测试在本地通过、在 CI 中失败（或反之），或者约每 N 次运行失败 1 次。
- 清理一批被
retry/skip标记掩盖真实不稳定问题的测试。
不适用于确定性失败的测试——那是真实 bug 或真实回归（使用 /absolute work 修复，或者直接修复即可）。deflake 的目标是非确定性失败。
扫描内容
通过实证确认不稳定性——不能因为有人这么说，就认定测试不稳定。使用配置中的
preferences.health.deflakeRuns 作为重复运行的默认次数 N（否则为 20）：
| 生态系统 | 重复运行 / 检测 |
|---|---|
| Jest/Vitest | 运行测试套件 N 次（--run 循环），随机调整顺序（--shuffle / testSequencer） |
| pytest | 使用 pytest-randomly + pytest --count=N（pytest-repeat）；使用 -p no:randomly 进行 A/B 测试 |
| Go | go test -count=N -shuffle=on ./...，以及 -race |
还要收集其他信号：现有的 retry/flaky/skip 注解、可获取的 CI 历史记录，并分别以单独运行和完整套件/并行运行的方式运行测试套件——依赖执行顺序和并发的问题，只有在其中一种情况下才会显现。记录每个疑似测试的失败率。
常见根本原因（诊断，不要猜测）
| 原因 | 判断依据 | 修复 |
|---|---|---|
| 测试顺序 / 共享状态 | 单独运行时通过，在套件中失败（或反之） | 隔离状态；在测试之间重置/清理 |
| 时间 / 时钟 | 接近午夜、夏令时切换或负载较高时失败 | 使用模拟计时器 / 注入时钟；不使用实际的 sleep |
| 异步竞争 / 遗漏 await | 并行运行或 CI 较慢时失败 | 等待实际条件；不使用固定超时 |
| 随机性 | 无明显规律地以约 X% 的概率失败 | 为随机数生成器设定固定种子；在测试中固定种子 |
| 网络 / 外部 I/O | 离线或网络缓慢时失败 | 对边界进行模拟/替身处理 |
| 无序集合 | 因 map/set 迭代顺序而失败 | 断言前先排序 |
| 资源泄漏 / 端口重用 | 重复运行或并行运行时失败 | 使用唯一资源；做好清理 |
风险排序（TRIAGE）
| 波次 | 类别 | 默认处理 |
|---|---|---|
| 1 | 原因明确且孤立（种子、await、模拟时钟、排序） | 立即修复 |
| 2 | 共享状态 / 执行顺序问题——需要重构 fixture | 在本轮中逐个测试修复 |
| 3 | 不稳定测试指向真实的产品竞争问题，而非单纯的测试问题 | 暂缓处理——标出；可能是需要修复的真实 bug |
不稳定测试有时意味着代码存在竞争问题，而不是测试的问题。不要为了“稳定”测试而掩盖真实的并发 bug——将第 3 波情况标出，以便进行真实修复。
修复与验证
- 修复原因。然后证明修复有效：多次重新运行测试（并随机调整顺序 / 并行运行 / 使用
-race）——只通过一次不算消除了不稳定性；在 N 次随机运行中均通过才算。 - 修复原因后，移除用于掩盖问题的
retry/skip/flaky注解。 - 绝不要通过增加重试次数、盲目延长超时、添加
sleep或跳过测试来“修复”——那只会掩盖不稳定性，无法消除它。 - 重新运行完整测试套件，确认修复没有导致相邻测试不稳定。
常见陷阱
- 通过重试／跳过来修复。 这会掩盖间歇性故障，却让不确定性随产品一起发布。在这里严禁这样做。
- 用
sleep来规避竞态。 这会拖慢测试套件，而且在负载较高时仍会出现间歇性故障。请等待条件满足。 - 一次通过就算完成。 间歇性故障具有概率性——请通过多次随机运行来验证。
- 稳定化实际的产品竞态。 如果是 代码 存在竞态，就修复代码，而不只是修改断言。
- 忽略顺序／并行维度。 在隔离环境中 和 测试套件中都运行；漏洞会藏在你跳过的任一场景中。
配套命令
/absolute upgrade—— 测试套件存在间歇性故障，会导致升级验证不可靠；请先消除间歇性故障。/absolute debt—— 间歇性测试标注属于测试债务；此命令会从根源上清除这些标注。/absolute work—— 当间歇性故障源于真正的产品代码竞态，需要进行实际的设计工作时使用。
评论
支持 Markdown