CCClaude Code中文喂饭教程

实战：让 CC 补测试

补测试不是追求覆盖率数字，而是证明本次修改的关键行为不会坏。要先让 CC 找到测试入口、相关用例和最小断言，再补低风险测试。

先让 CC 找测试风格

补测试之前先看项目已有测试。不要上来就让 CC 发明一套新测试框架。

/plan

请先只读分析当前项目的测试方式，不要新增测试。

请告诉我：
1. 项目使用什么测试框架。
2. 现有测试文件放在哪里。
3. 命名风格和断言风格是什么。
4. 本次任务最应该补哪类测试。
5. 如果项目没有测试，建议最小验证方式是什么。

什么时候需要补测试

优先补这些测试：

修改类型优先测试
Bug 修复回归测试，证明旧问题不会再出现
接口逻辑正常输入、异常输入、兼容性
权限判断有权限、无权限、边界角色
数据处理空值、重复值、极端值
重构行为不变测试

补测试前先判断测试价值：

问题如果答案是“是”
这个行为以后容易被改坏吗值得补测试
这个 Bug 可能复发吗值得补回归测试
这个逻辑影响数据、权限或金额吗优先补测试
这个测试只是在测实现细节吗先不要补
项目完全没有测试基础吗先做人工验收或 smoke check

什么时候不强求测试

确认后补测试

可以按现有测试风格补充最小必要测试。

要求：
1. 只覆盖本次修改相关行为。
2. 不要为了测试重构业务代码。
3. 不要引入新测试框架。
4. 运行相关测试并解释结果。
5. 如果测试无法运行，请说明原因和人工验收方法。

让 CC 找最小断言

测试不是越多越好，关键是断言要对。

请先设计测试断言，不要写代码。

要求：
1. 本次修改最关键的行为是什么。
2. 哪个断言能证明它正确。
3. 哪个断言能证明 Bug 不会复现。
4. 哪些断言属于实现细节，不建议测试。
5. 最小测试用例数量是多少。

测试命名也要跟项目一致

请先观察现有测试命名和描述风格。

要求：
1. 测试文件名遵循项目已有风格。
2. 用例描述和现有项目一致。
3. 不为了新增一个测试引入新目录规范。
4. 如果没有明确风格，请选择最简单、最容易理解的命名。

测试应该覆盖什么

不要让 CC 为了好看而补无意义测试。测试要证明关键行为。

运行测试后怎么看

请解释测试结果。

要求：
1. 哪些测试通过。
2. 哪些测试失败。
3. 失败是否由本次修改引入。
4. 是否存在历史失败。
5. 是否需要最小修复。
6. 不要因为历史失败扩大本次任务。

让 CC 说明测试价值

请解释刚才新增的测试。

要求：
1. 每个测试覆盖什么行为。
2. 为什么这个行为和本次修改相关。
3. 哪些风险仍然没有覆盖。
4. 测试是否会因为实现细节变化而过于脆弱。
5. 是否有更小的测试方案。

如果项目没有测试

当前项目似乎没有现成测试体系。

请不要直接引入新框架。
请给出替代验收方案：
1. 可以运行哪些已有检查。
2. 可以做哪些手动验证。
3. 如果未来要补测试，最小引入方案是什么。
4. 本次任务是否值得现在引入测试框架。

常见跑偏

测试失败时怎么收口

新增测试失败了，请先不要扩大修改。

请判断：
1. 是测试写错，还是业务代码有问题。
2. 失败是否和本次修改直接相关。
3. 最小修复应该改测试还是改代码。
4. 是否暴露了历史问题。
5. 在我确认前不要重构测试体系。

什么情况下先不补测试

有些项目确实没有测试基础。此时不要为了“看起来专业”强行上框架。

可以先做：

补测试收尾报告

请总结这次补测试。

请说明：
1. 新增或修改了哪些测试。
2. 每个测试覆盖什么行为。
3. 跑了哪些测试命令。
4. 是否有未覆盖风险。
5. 是否建议进入 /code-review。

验收结果

下一篇：安全重构