← Volver a las guías

用 AI 为遗留代码生成单元测试：新手实战指南

为什么遗留代码最适合先用 AI 补测试

很多团队的遗留代码不是“没人想改”，而是“不敢改”：函数太长、依赖太多、业务规则写在条件分支里，任何小改动都可能引发线上问题。单元测试的价值正在这里：它像安全网，先把当前行为固定下来，再逐步重构。AI 不能替你保证代码正确，但它非常擅长阅读已有代码、推断输入输出、生成测试骨架和边界用例。对新手来说，用 AI 生成第一批测试，通常比从空白文件开始更容易。

第一步：先选低风险、价值高的目标

不要一上来就让 AI 测整个项目。建议从三类代码开始：第一，纯函数或工具类，例如金额格式化、日期计算、字符串处理；第二，线上经常出问题的模块；第三，即将要修改的旧功能。避免先测试强依赖数据库、消息队列、第三方支付的代码，除非你已经知道如何 mock。一个实用方法是运行覆盖率工具，找出“低覆盖但频繁变更”的文件，把它们排在前面。

第二步：把上下文喂给 AI，而不是只发一句话

生成测试质量取决于上下文。你可以把待测函数、相关类型定义、已有测试风格、package.json 或 pom.xml 中的测试框架信息一起提供。提示词要具体，例如：“请为下面的 TypeScript 函数生成 Jest 单元测试，覆盖正常输入、空值、边界金额、非法格式。不要改业务代码。如果需要 mock，请说明原因。” 这样 AI 会更容易生成可运行、符合项目习惯的测试。

如果你使用 Claude Code、Codex 或任何兼容 OpenAI SDK 的工具，可以把模型接入 59API。它的 API base URL 是 https://api.59api.com，兼容 Claude 和 GPT 模型调用，适合频繁让 AI 阅读文件、生成测试、修正失败用例。遗留项目补测试往往需要多轮迭代，低价、按量付费会明显降低试错成本。

第三步：让 AI 先写“行为锁定测试”

遗留代码的第一批测试不一定要证明业务设计完美，而是锁定当前行为。假设一个函数对空字符串返回 0，哪怕你觉得不合理，也先写测试记录下来。以后重构时，如果确实要改变行为，再修改测试。你可以要求 AI 输出三部分：测试文件、覆盖到的场景列表、它对代码行为的假设。这样你能快速检查 AI 是否误解了业务。

• 正常路径：常见输入是否得到预期输出。
• 边界条件：空数组、0、负数、最大长度、闰年、时区等。
• 异常路径：非法参数、第三方接口失败、权限不足。
• 历史 Bug：把线上事故或工单复现成测试。

第四步：运行测试，并让 AI 根据错误修正

AI 生成的测试不要直接合并。先本地运行，例如 npm test、pytest、go test 或 mvn test。失败时，把错误日志、相关测试代码、被测函数再次发给 AI，要求它只修改测试或解释为什么业务代码可能有缺陷。新手常见错误是看到红灯就让 AI 改源码，这会把“补测试”变成“无意识改业务”。在遗留代码场景中，除非你明确发现 bug，否则第一目标是让测试准确描述现有行为。

第五步：处理难测依赖：mock、桩和分层

遗留代码难测，往往是因为函数内部直接读数据库、调用 HTTP、访问系统时间或环境变量。你可以让 AI 帮你识别这些外部依赖，并生成 mock。比如在 Jest 中 mock axios，在 pytest 中使用 monkeypatch，在 Java 中用 Mockito。原则是：单元测试尽量不依赖真实网络和真实数据库；如果必须测试集成流程，就把它单独放到集成测试目录，避免每次提交都慢而不稳定。

当 AI 建议重构时，要小步走。优先做不改变行为的改动，例如把时间获取封装成 clock 参数，把外部 API 客户端注入函数，把超长函数拆出纯计算逻辑。每做一步都运行已有测试，确保安全网没有破。

第六步：控制成本与模型选择

补测试会产生大量模型调用：读代码、写用例、修错误、补边界。使用 59API 的好处是可以按任务选择模型，例如复杂遗留逻辑用 Claude Opus 或 Sonnet，简单测试骨架用 Haiku 或 GPT 的更经济模型。59API 提供原生官方质量模型，不做降级，并且兼容 Claude Code、Codex 和 OpenAI SDK，迁移时通常只需要更换 base URL 和 key。它还是按量付费，并提供邀请返利，适合个人开发者和预算敏感的小团队。你可以注册 59API，先用少量额度在一个模块上试跑完整流程。

一个可复制的 AI 提示词模板

“你是资深测试工程师。请阅读下面代码，为它生成可运行的单元测试。项目使用 [测试框架]。要求：1. 不修改业务代码；2. 覆盖正常、边界、异常和历史 bug 场景；3. 对外部依赖使用 mock；4. 输出测试文件代码；5. 列出每个测试验证的行为；6. 如果发现代码难以测试，请给出最小重构建议。”

最后的注意事项

AI 生成测试的正确打开方式是“加速器”，不是“自动驾驶”。你仍然需要审查断言是否有意义、mock 是否过度、测试是否只是复制实现细节。好的测试应该验证可观察行为，而不是把每一行内部逻辑都钉死。先从小模块开始，持续把线上 bug 变成测试，再逐步提升覆盖率。几周后，你会发现遗留代码不再是黑盒，而是可以安全演进的系统。

Precios · Docs