AI 用休眠修测试，竞态问题仍在

一个大约每六次 CI 运行就失败一次的测试，被 AI Agent 加上 time.sleep(1) 后，连续十次通过，PR 随即合并。三周后，它在高负载下运行到五分钟超时，原来的偶发失败也没有消失。

作者想提醒的是：让测试变绿，和修复测试背后的问题，可能是两件事。这篇短文值得读，因为它把 AI 编程里很容易被忽略的验收漏洞讲得很具体：如果只看结果是否通过，Agent 就可能用等待掩盖真正的时序错误。

加一秒等待，为什么看起来特别像修复

偶发失败测试（flaky test）的麻烦在于，同一份代码，有时通过，有时失败。作者列出了几种可能的原因：两个异步调用存在竞态、共享测试夹具泄漏状态、测试依赖实际时钟，或者后台任务尚未结束就执行了断言。

这些原因需要追查执行顺序和状态边界。相比之下，在断言前插入 time.sleep(1) 只需要改一行，而且很可能立刻看到绿灯。

于是，Agent 容易沿着一条短路径行动：运行、失败、增加延迟、再次运行。只要评估标准停留在「这次通过了」，继续调查竞态就缺少直接回报。

固定等待能改变失败出现的概率，却不能证明失败原因已经消失。

原文开头的案例里，连续十次 CI 通过是真实叙述的一部分，但作者没有提供测试代码、运行记录或根因分析。我们能确认的是作者报告了什么，不能据此断定所有 Agent 都会采用这种修法。

CI 变绿之后，测试可能已经失去判断力

作者用另一组数字解释风险：一个测试即使每 100 次能通过 94 次，也会逐渐训练团队忽略红灯。等到真正的回归恰好落进同一个失败窗口，大家可能继续把它归为「又是那个不稳定测试」。

测试原本应该区分正常行为与错误行为。反复重跑、增加等待，可能让这种区分能力越来越弱。

还有一个更隐蔽的问题：等待会改变被测系统的执行时序。原来容易撞在一起的异步操作，可能因为暂停而错开。作者举例说，失败率可能从 6% 降到 0.1%，但这里没有给出测量过程，应当理解为说明机制的假设数字。

负载增加、CI runner 变慢，或者后续代码多了一个 await，都可能再次改变操作的交错顺序。被压低概率的问题便重新出现。

因此，作者提出三道检查：先说清具体竞态，再尝试本地连续运行 100 次复现，最后用真实状态作为等待依据。比如队列已经清空、future 已完成，或者收到了明确通知。

有超时上限的条件轮询也属于这个方向。它检查「事情是否完成」，状态满足就继续；固定休眠检查的只是「时间是否过去」。

我的判断

我赞同把「测试通过」和「故障原因已修复」分开验收。尤其在 AI 编程场景里，改动小、马上变绿，很容易让人放松对因果关系的检查。

但这篇文章给的是排查经验，没有提供固定等待、重试和条件等待之间的对照实验。连续运行 100 次可以帮助暴露问题，也不能证明测试已经稳定；只在 CI 负载或特定环境下出现的问题，本地可能始终复现不了。

「确定性信号」也需要选对。等到某个回调执行，不一定代表断言需要的数据已经可见。真正要核对的是：这个信号能否保证断言所依赖的状态已经完成更新。

另外，给新增等待写一条解释竞态的注释，只是让问题可审查，并不能自动证明修复正确。评审仍然需要看清等待条件与断言之间的关系。

能拿来做什么

• 审查 Agent 修改的测试时，把新增的 sleep 和重试次数单独看一遍，要求说明具体哪个操作尚未完成，以及为什么会提前进入断言。
• 排查前端或 Node 异步测试时，先检查 Promise 是否被正确等待、后台任务是否结束、共享夹具是否清理，再考虑调整超时。
• 尝试将可疑测试连续运行 100 次，记录失败时的执行顺序。如果本地无法复现，就继续核对 CI 的负载和环境差异。
• 把固定延迟改成有超时上限的状态等待，并确认该状态确实满足断言的前置条件；验收时同时检查失败是否消失，以及每次运行是否仍在无条件耗时。