用 Codex 修改代码以后，经常会遇到一种情况：

代码看起来已经改对了，但测试就是一直失败。

常见表现包括：

• 业务逻辑已经更新，测试还在报错；

• 单独运行一个测试能过，跑全部测试却失败；

• 本地能通过，换个环境又失败；

• Codex为了让测试变绿，开始不断修改断言；

• 改了几轮以后，反而越来越难判断到底是代码错，还是测试错。

这种问题不要急着继续改代码。

更重要的是先分清：

失败的是业务实现、测试命令、测试数据，还是测试预期本身。

一、先确认测试命令是不是跑对了

很多项目里并不只有一套测试命令。

例如：

npm test

和：

npm run test:unit

或者：

npm run test:integration

跑的内容可能完全不同。

所以遇到失败时，先确认：

• 当前跑的是哪类测试；

• 是否只跑了单个文件；

• 是否遗漏了初始化步骤；

• 项目有没有专门的测试脚本。

最好优先使用项目已经定义好的命令，不要让 Codex自己猜。

---

二、先看第一个真正失败的测试

一次跑完整测试时，可能出现几十个失败。

这时候不要让 Codex直接逐个修。

因为很多后续错误，可能都是第一个问题引起的连锁反应。

更稳的做法是：

先分析第一个失败测试，不修改其他地方。

确认：

• 错误信息是什么；

• 预期值是什么；

• 实际值是什么；

• 哪一步开始出现差异。

先找到第一个根因，往往比同时处理几十个报错效率更高。

---

三、业务逻辑变了，测试预期可能还是旧的

例如原来接口返回：

401

新需求改成：

403

业务代码已经按新需求修改。

但测试仍然写着：

expect(status).toBe(401)

这时候测试失败并不一定说明代码错了。

需要先确认：

需求本身有没有变化。

如果新行为是明确要求，那么测试也需要同步。

但如果需求没有变化，就不能为了让测试通过随便改断言。

---

四、不要为了“跑绿”直接修改断言

这是 AI 编程里非常值得注意的一点。

测试失败以后，最容易出现的做法就是：

expect(result).toBe("old")

直接改成：

expect(result).toBe("new")

测试马上通过。

但问题是：

“new”到底是不是正确结果？

如果没有先确认业务规则，这种修改只是把测试改成接受当前实现。

测试存在的意义就没了。

所以可以提前告诉 Codex：

测试失败时不要直接修改断言，先解释当前预期和实际结果为什么不同。

---

五、测试数据过期也会导致一直失败

很多测试依赖：

• Mock数据；

• Fixture；

• Seed数据；

• 测试数据库。

如果业务字段已经变化，测试数据还是旧结构，也可能失败。

例如类型新增：

avatar

但测试数据里仍然只有：

id
name

代码本身可能没问题。

真正需要同步的是测试数据。

所以涉及类型、Schema、接口字段变化时，也要顺便检查：

测试数据是否还是旧版本。

---

六、单独能过，全部一起跑却失败，要注意测试相互影响

如果：

单个测试通过

但：

全部测试一起运行失败

可能说明测试之间共享了某些状态。

例如：

• 同一个数据库；

• 全局变量；

• 缓存；

• 临时文件；

• Mock没有恢复。

这时候问题不一定在业务代码。

而可能是：

前一个测试留下了状态，影响了后一个测试。

可以检查：

• 测试前是否初始化；

• 测试后是否清理；

• Mock是否恢复；

• 数据是否隔离。

---

七、本地能过，CI失败要检查环境差异

如果 Codex 本地执行测试全部通过，但 CI 失败，可以继续确认：

• Node/Python版本是否一致；

• 依赖是否按锁文件安装；

• 环境变量是否完整；

• 数据库和服务版本是否一样；

• 操作系统是否不同。

测试结果不仅取决于代码。

也取决于：

运行测试的环境。

所以“本地绿了”不等于所有环境都会自动通过。

---

八、一个比较稳定的排查顺序

Codex改完代码以后测试失败，可以按下面顺序处理：

第一步：确认测试命令。

先保证跑的是正确测试。

第二步：定位第一个失败项。

不要一次修全部。

第三步：比较预期值和实际值。

确认到底哪里开始不同。

第四步：检查需求是否真的发生变化。

判断测试该不该改。

第五步：检查Mock和测试数据。

确认数据结构没有过期。

第六步：再检查环境差异。

尤其是本地和CI结果不同的时候。

---

九、可以给Codex一个测试失败处理规则

以后涉及真实项目，可以提前增加：

测试处理要求：

1. 测试失败后先分析原因；
2. 不允许为了通过测试直接修改断言；
3. 先处理第一个根因；
4. 检查测试数据是否与当前代码一致；
5. 修改完成后重新运行相关测试；
6. 最后再跑完整测试。

这样比：

测试失败了，继续修。

更稳定。

---

最后

Codex修改代码后测试一直失败，不一定说明：

业务代码一定写错了。

真正需要判断的是：

• 测试命令对不对；

• 第一个错误在哪里；

• 需求有没有变化；

• 测试预期是否过期；

• Mock和测试数据是否同步；

• 环境是否一致。

尤其要避免一个误区：

看到测试失败，就直接修改断言让它变绿。

更稳的做法应该是：

先解释为什么失败，再决定应该改实现还是改测试。

只要把这个顺序理清，很多“代码已经改完但测试一直红”的问题都会更容易定位。

---

持续更新 Codex、大模型开发与 AI 编程实战内容，更多技术内容与稳定订阅渠道欢迎搜索关注「仙逆GPT」。