Claude Code 自动写测试教程：单元测试、集成测试、回归检查

Claude Code 不只可以修 Bug 和重构代码，也很适合补测试。它能读取项目里的测试框架、现有用例风格、构建命令和业务代码，再根据目标函数或用户流程生成单元测试、集成测试和回归检查。不过，自动写测试并不等于测试一定有效。真正有价值的测试必须能覆盖关键行为、能在错误时失败、能被项目命令稳定运行。

本文会讲清从识别测试栈到生成测试用例的完整流程。还没完成 Claude Code 安装配置的读者，可以先看本站 安装部署教程 和 环境配置教程；已经能运行项目的读者，可以把本文作为 实战工作流 和 问题排查教程 的测试补齐模板。

摘要

使用 Claude Code 自动写测试，推荐按四步执行：先只读分析项目测试栈，找出使用的是 Jest、Vitest、Pytest、Playwright 还是其他框架，并确认测试目录、命名规则、运行命令和 mock 风格；再让它为纯函数、工具函数、边界值和异常分支生成单元测试；接着为组件交互、接口流程、数据库或服务调用写集成测试；最后围绕历史 Bug 和关键用户路径建立回归检查。每次生成测试后，都要运行测试命令、检查失败原因、审查断言是否有效，避免只断言“函数被调用”或硬编码实现细节。Claude Code 可以自动生成和修正测试，但权限确认、diff 审查和测试价值判断必须由开发者完成。

正文

为什么先识别测试栈

测试不是独立文本，它必须符合项目已有框架、目录结构和命名习惯。如果项目已经使用 Vitest，却让 Claude Code 写 Jest 风格测试；如果组件测试已经统一使用 Testing Library，却生成了直接访问内部状态的测试，后续维护成本会很高。

所以第一步不是让 Claude Code 马上写测试，而是让它先读取项目里的测试配置和现有用例。

第一步：让 Claude Code 只读分析测试栈

在项目根目录启动 Claude Code，先要求它只读分析，不要修改文件：

请先只读分析这个项目的测试栈，不要修改文件。
请输出：
1. 使用了哪些测试框架
2. 测试文件目录和命名规则
3. 常用测试命令
4. Mock、fixture、setup 文件在哪里
5. 现有测试风格有什么特点
6. 哪些关键模块缺少测试

官方 CLI 文档说明，Claude Code 可以在交互模式中使用，也支持 print 模式、继续最近会话和管道输入。实际补测试时，建议用交互模式，因为你需要逐步确认计划、权限和失败日志。

第二步：先写单元测试

单元测试适合覆盖纯函数、工具函数、数据转换、格式化逻辑、校验规则和错误处理。它们通常依赖少、运行快、失败原因清楚，适合作为 Claude Code 自动写测试的起点。

请为 src/shared/validation/email.ts 写单元测试。
要求：
1. 先读取现有测试风格
2. 覆盖正常邮箱、空字符串、非法格式、大小写、前后空格
3. 不要修改实现文件
4. 生成测试后运行对应测试命令
5. 如果失败，先解释原因再修正测试

好的单元测试应该围绕行为，而不是围绕实现细节。比如测试“非法邮箱返回 false”，比测试“内部调用了某个正则”更稳定。

第三步：覆盖边界值和异常分支

Claude Code 容易先生成最常见的 happy path，用例看起来很多，但真正能发现问题的不多。你应该明确要求它覆盖边界值、异常输入和历史问题。

请补充边界和异常分支：
- null / undefined
- 空数组
- 重复数据
- 超长字符串
- 非法枚举值
- API 返回缺少字段
- 历史 Bug 的复现场景

第四步：再写集成测试

集成测试关注多个模块如何协作，例如用户提交表单后是否调用正确 API、接口响应后状态是否更新、错误时是否显示提示、缓存是否刷新。它比单元测试更接近真实业务路径，也更容易暴露模块边界问题。

请为用户保存资料流程写集成测试。
要求：
1. 按现有测试框架和 mock 风格编写
2. 覆盖保存成功、保存失败、按钮 loading、错误提示
3. 不要真实请求后端
4. 不要改业务代码，除非测试暴露出明确问题并先说明
5. 写完后运行相关测试

第五步：建立回归检查

回归测试最适合围绕历史 Bug 和关键业务路径建立。比如某个 Bug 是“保存按钮点击后没有提示成功”，那回归测试就应该复现这个路径，并断言成功提示出现。不要只测试函数返回值，要覆盖原问题是否会再次发生。

请根据这个历史 Bug 写回归测试：
Bug：点击保存按钮后接口成功，但页面没有显示成功 toast。
要求：
1. 测试必须在旧问题复现时失败
2. 修复后测试通过
3. 使用现有 mock 和渲染工具
4. 不要只断言函数被调用，要断言用户可见结果

第六步：运行测试并修正失败

测试生成后必须运行。Claude Code 在执行测试命令时可能需要权限确认；官方安全说明也强调，编辑文件、执行测试和运行命令需要明确权限。你应该看清它要运行的命令是否和任务相关。

npm test
npm run test:unit
npm run test:integration
npm run lint

如果测试失败，不要直接删除断言或放宽条件。把失败日志交给 Claude Code，让它判断是测试写错、mock 不完整，还是业务代码真的有问题。

第七步：审查测试是不是伪测试

伪测试是自动写测试里最常见的问题。它看起来覆盖了代码，但实际无法保护行为。常见表现包括：只断言组件能渲染、不验证用户结果；只断言函数被调用、不验证参数；mock 掉被测逻辑；断言实现细节；为了通过测试而改弱断言。

你可以让 Claude Code 自查：

请审查刚才生成的测试是否有伪测试风险：
1. 断言是否验证真实用户可见行为
2. 是否 mock 掉了被测核心逻辑
3. 测试在错误实现下是否会失败
4. 是否过度依赖实现细节
5. 是否需要补充边界用例

第八步：让测试和实现分开提交

如果是给现有功能补测试，建议先提交只新增测试的 diff；如果测试暴露出 Bug，再单独提交修复。这样可以清楚区分“补保护网”和“改业务逻辑”。

如果是测试驱动修复历史 Bug，则可以先让 Claude Code 写一个失败的回归测试，再修复实现，最后确认测试通过。

第九步：把测试命令写进 CLAUDE.md

如果项目长期使用 Claude Code，可以把测试命令、测试风格和禁止事项写进 CLAUDE.md，减少每次重复说明。

# Test Rules
- 单元测试使用 Vitest。
- 组件测试使用 Testing Library。
- 不要 mock 被测核心函数。
- 回归测试必须覆盖用户可见行为。
- 修改测试后运行 npm run test:unit。

第十步：完整提示词模板

下面是一段可以直接复制使用的模板：

请帮我为这个项目补测试。
当前阶段先只读分析测试栈，不要修改文件。

目标：
【例如：为保存资料流程补单元测试和回归测试】

要求：
1. 先读取现有测试框架、目录、命名规则和 mock 风格
2. 输出测试计划，说明单元测试、集成测试、回归测试分别覆盖什么
3. 不要修改业务代码，除非测试暴露出明确 Bug 并先说明
4. 测试必须验证真实行为，不要写伪测试
5. 写完后运行相关测试命令
6. 如果失败，解释失败原因并修正

请先给测试计划，等我确认后再写文件。

什么时候先不要自动写测试

如果项目连基本运行命令都不清楚、依赖安装失败、测试框架混乱、业务需求没有定义，建议先让 Claude Code 做只读梳理，不要马上生成大量测试。否则很容易写出不能运行、不能维护的用例。

FAQ

Claude Code 可以一次性给整个项目补测试吗？

不建议。应该按模块和风险分批补测试，先补关键函数、历史 Bug 和核心用户流程，再逐步扩大覆盖范围。

自动生成的测试一定可靠吗？

不一定。必须运行测试并审查断言。重点看测试是否验证真实行为、是否能在错误实现下失败、是否符合项目已有测试风格。

单元测试和集成测试应该先写哪个？

通常先写单元测试，因为更小、更快、更容易定位问题；然后为关键用户流程补集成测试和回归检查。

Claude Code 写测试时可以改业务代码吗？

默认不建议。先只补测试。如果测试暴露出真实 Bug，再让 Claude Code 单独给出修复计划，确认后再改业务代码。

如何避免伪测试？

要求测试验证用户可见结果或真实输出，不要只断言函数被调用；不要 mock 掉被测逻辑；让 Claude Code 自查测试在错误实现下是否会失败。