让 Codex 为现有代码补测试

补测试的目标不是追求一个好看的覆盖率数字，而是把关键行为变成可重复验证的证据。

教程目标

完成后，你能让 Codex 为一段已有代码补测试，并证明测试在修复前能暴露问题、修复后能够通过。

开始前准备

• 项目已有可运行的测试框架；如果没有，先让 Codex只读比较可选方案。
• Git 工作区干净，或已记录原有改动。
• 选一个边界清楚的函数、组件或接口，不要第一次就覆盖全项目。

第 1 步：确认测试基线

请先只读检查当前项目的测试体系，不要修改文件。

请说明：
1. 使用什么测试框架和断言库。
2. 测试文件放在哪里、如何命名。
3. package.json 或构建文件里真实存在的测试命令。
4. 当前测试是否通过；如果不能运行，说明原因。
5. 目标模块已有哪几类测试、还缺什么关键行为。

先保存基线结果。已有失败不能被误算成本次新增测试造成。

第 2 步：写行为清单

要求 Codex 先列测试表，不直接写代码：

请为【目标模块】设计最小测试集合，先不要修改文件。

至少覆盖：
- 一个正常路径；
- 一个边界值；
- 一个失败或异常路径；
- 本次需求明确要求的回归场景。

每条写清输入、预期输出、为什么值得测。不要测试实现细节。

删除重复、脆弱或与需求无关的用例后，再批准实现。

第 3 步：只补测试

按确认后的测试表实现测试。

限制：
1. 这一轮只允许修改测试文件和必要的测试夹具。
2. 不要修改业务代码来迎合测试。
3. 复用项目现有测试风格，不新增无必要依赖。
4. 先运行最小相关测试，再运行完整测试。
5. 展示 diff 和实际命令结果。

如果测试失败，让 Codex 判断是测试假设错、环境问题，还是确实暴露业务缺陷。不要看到红灯就立刻改业务代码。

第 4 步：验证测试有效性

对 Bug 回归测试，最有价值的证据是：测试在旧行为上失败，在修复后通过。可以让 Codex 使用临时、可恢复的方法验证，但必须保留用户原有改动并恢复现场。

请证明新增回归测试确实能捕获目标问题。
不要破坏或覆盖我的现有改动；如果无法安全验证，就明确写“未验证”，不要伪造结果。

常见问题

• 只断言“没有抛错”：通常太弱，应断言可观察结果。
• 大量 mock：可能在测试 mock 自己，优先保留真实边界。
• 快照过大：小改动会产生噪音，应缩小到稳定输出。
• 为通过测试改生产逻辑：拆成下一轮修复，并说明原因与风险。
• 覆盖率上升但关键分支没测：回到行为清单，而不是继续堆用例。

验收结果

1. 测试命令来自项目真实配置，基线有记录。
2. 新测试覆盖正常、边界、失败和目标回归路径。
3. diff 没有无关业务修改或新增依赖。
4. 最小测试与完整测试均有真实结果。
5. 回归测试的捕获能力已验证，或明确记录未验证原因。

下一篇看：让 Codex 完成任务验收。