Codex 自动写测试教程：单元测试、报错修复和回归检查

很多人使用 Codex 时只关注生成代码，却忽略了测试。真正可靠的 AI 编程工作流，不只是让 Codex 写功能，还要让它补测试、读失败日志、修复问题并做回归检查。这样才能减少“看起来能跑，实际有坑”的风险。

如果你正在搭建 AI 编程流程，可以继续查看站内 实战工作流；如果你经常处理报错，也可以阅读 问题排查教程 和 使用技巧教程。

为什么要让 Codex 自动写测试

测试是 AI 编程的护栏。Codex 可以快速理解函数、组件和接口的行为，但如果没有测试，修改是否正确只能靠人工观察。自动写测试的价值，是把需求变成可重复验证的规则，让每次修改都有明确反馈。

测试能解决什么问题

测试可以发现边界条件、空数据、异常输入、权限问题和回归风险。对于 WordPress 自动发布、前端表单、API 接口和数据处理脚本，测试尤其重要，因为这些场景一旦出错，可能影响线上内容或用户体验。

不要只让 Codex 写 happy path

很多自动生成的测试只覆盖“正常输入正常输出”。更实用的测试应该覆盖异常输入、缺失字段、权限不足、接口失败、旧数据兼容和重复提交。写 Prompt 时要明确要求 Codex 补这些边界场景。

第一步：让 Codex 理解被测代码

让 Codex 写测试之前，不要直接说“给这个文件写测试”。更好的做法是先让它阅读目标函数、调用方、已有测试风格和项目测试命令。只有理解上下文，生成的测试才会贴合项目。

推荐提示词

请先阅读目标文件和项目已有测试，不要马上修改。
请总结：
1. 这个函数或模块的主要行为；
2. 输入和输出是什么；
3. 可能的边界情况；
4. 项目当前使用什么测试框架；
5. 应该新增哪些测试用例。

这一步能避免 Codex 生成和项目风格不一致的测试，也能先暴露信息不足的问题。

第二步：生成单元测试用例

单元测试关注最小行为单元。对于函数来说，要测试输入输出；对于组件来说，要测试渲染和交互；对于接口处理函数来说，要测试参数校验、权限、成功响应和错误响应。

单元测试 Prompt 模板

请为 [函数/模块名称] 补充单元测试。
要求：
1. 参考项目已有测试写法；
2. 覆盖正常输入、空输入、非法输入和边界值；
3. 必要时使用 mock，不要访问真实外部服务；
4. 不要修改业务逻辑，除非测试暴露真实 Bug；
5. 完成后运行相关测试命令。

测试命名要清楚

测试名称应该描述行为，而不是描述实现。例如“缺少标题时返回校验错误”比“test case 1”更有价值。以后测试失败时，开发者可以直接从名称看出业务规则。

第三步：根据失败日志修复问题

测试失败不一定是坏事。它可能说明 Codex 写错了测试，也可能说明业务代码本身存在 Bug。正确流程是先分析失败原因，再决定修改测试还是修改业务代码。

失败日志 Prompt 模板

以下测试失败了：[粘贴失败日志]。
请分析失败原因：
1. 是测试预期写错，还是业务代码有 Bug；
2. 失败发生在哪个文件和哪一行；
3. 最小修复方案是什么；
4. 修复后需要重新运行哪些测试。
不要为了通过测试而隐藏真实问题。

不要盲目改断言

测试失败时，最危险的做法是直接把断言改成当前错误结果。Codex 应该先解释业务期望，再判断当前实现是否符合期望。只有测试本身写错时，才应该修改测试。

第四步：补充回归检查

回归检查用于防止旧 Bug 重复出现。每修复一个问题，都可以把复现步骤转成测试或检查清单。这样下一次改代码时，测试会自动提醒你不要破坏已有行为。

回归测试 Prompt 模板

请根据这个已修复 Bug 补充回归测试。
Bug 现象：[描述]
修复方式：[描述]
要求测试能在未来同类问题再次出现时失败。
请保持测试范围最小，并说明如何运行。

哪些场景最值得做回归

登录权限、支付流程、文章发布、文件上传、表单提交、SEO 字段写入、缓存刷新和数据迁移，都值得补回归测试。对站长项目来说，自动发布脚本和内容生成流程也应该保留回归检查。

第五步：建立测试分层

不是所有问题都适合用同一种测试解决。单元测试快，适合检查函数逻辑；集成测试适合检查模块协作；端到端测试适合检查真实用户路径；截图检查适合验证页面视觉和布局。

测试分层建议

• 单元测试：验证函数、工具方法和纯逻辑。
• 集成测试：验证接口、数据库、权限和模块协作。
• 端到端测试：验证关键用户路径。
• 截图检查：验证页面布局和视觉回归。
• 手动清单：验证无法自动化的业务流程。

不要追求一次性全覆盖

测试覆盖率不是越快堆越好。更实际的做法是优先覆盖高风险模块和经常出错的路径。每次修复 Bug 时补一个回归测试，长期积累会比一次性大补更稳。

第六步：让 Codex 输出测试报告

测试跑完后，不要只看“通过”或“失败”。可以让 Codex 汇总测试命令、覆盖范围、失败原因、修复摘要和剩余风险。这样的报告适合放进 Pull Request 或发布记录。

测试报告 Prompt 模板

请根据本次测试结果生成简短报告。
包括：
1. 运行了哪些测试命令；
2. 新增或修改了哪些测试；
3. 覆盖了哪些业务场景；
4. 是否有失败项；
5. 还有哪些剩余风险。

发布前检查

如果测试涉及 WordPress 自动发布或线上内容，发布前还要确认文章状态为 draft、密钥只从环境变量读取、没有删除线上文章、没有修改主题核心文件。这些规则应写入项目说明，避免自动化越界。

适合直接复用的 Codex 测试工作流

推荐流程是：明确被测目标，阅读已有测试，列出测试用例，生成单元测试，运行测试，根据失败日志修复，补回归检查，输出测试报告。这个流程适合沉淀到团队的 实战工作流。

完整 Prompt 示例

请为当前模块补充测试。
步骤：
1. 先阅读相关代码和已有测试；
2. 总结模块行为和边界场景；
3. 提出测试用例清单，等我确认后再写代码；
4. 生成测试后运行相关命令；
5. 如果失败，先分析原因，再做最小修复；
6. 最后输出测试报告和剩余风险。

常见问题

Codex 写的测试一定可靠吗？

不一定。Codex 可以高效生成测试草案，但仍需要人工确认业务预期，尤其是权限、支付、数据删除和线上发布等高风险场景。

测试失败时应该先改代码还是改测试？

先分析失败原因。如果业务代码不符合需求，应改代码；如果测试误解了需求，才改测试。不要为了通过测试随意降低断言。

没有测试框架的项目怎么办？

可以先让 Codex 识别项目技术栈，再建议合适的最小测试方案。也可以先写手动回归清单，逐步引入自动化测试。

WordPress 自动发布脚本需要测试什么？

至少要测试环境变量读取、默认 draft 状态、分类 ID 校验、图片 alt_text、SEO 字段、失败错误输出和不泄露密钥。