跳转到主内容TDD 工作流:用 Claude Code 做测试驱动开发
很多开发者对 TDD(Test-Driven Development,测试驱动开发)的态度是:道理我都懂,但真做起来太累了。
先写测试,再写代码,每改一点就要跑一遍——这个循环在理论上很完美,在实践中很磨人。大部分人尝试过几次之后就放弃了,回到了"先写代码后补测试"的老路,而"后补"往往就变成了"不补"。
Claude Code 让这件事变得不一样。它能帮你写测试、跑测试、读懂报错、改代码,TDD 循环里最烦人的那些步骤,恰好是 AI 最擅长的。
什么是 TDD
TDD 的核心是三个步骤的循环,通常用颜色来标记:
红(RED):先写一个测试,描述你期望的行为。这时候功能代码还没写,测试一定会失败——终端显示红色。
绿(GREEN):写最少的代码,让测试通过。不追求优雅,不考虑扩展性,只要能让终端变绿就行。
重构(REFACTOR):测试通过了,现在可以安心重构。改善代码结构、消除重复、优化命名——因为有测试兜底,你知道改完之后功能还是对的。
然后回到红色,写下一个测试,循环继续。
RED(写测试)→ GREEN(写最小实现)→ REFACTOR(重构)→ 回到 RED
这个流程的好处是:你永远在一个"安全网"里写代码。每一次修改都有测试确认对错。
为什么 Claude Code 特别适合 TDD
写测试这件事,AI 比人快得多。 你描述一下函数应该做什么,Claude Code 就能生成覆盖正常路径和边界条件的测试。人类写测试时容易忽略的 edge case(空字符串、超长输入、特殊字符),AI 会本能地想到。
跑测试不用切窗口。 Claude Code 直接在对话里执行测试命令,红了它能读懂报错;绿了它会问你要不要继续。
重构时有 AI review。 Claude Code 改完代码会自动跑测试确认。你可以大胆让它重构,因为测试会兜住。
循环的节奏变快了。 传统 TDD 一个循环可能要十几分钟,和 Claude Code 配合,几分钟就能走完一轮。
一句话总结:TDD 的重复性步骤正好是 AI 的强项,人负责决策,AI 负责执行。
完整实战:用 TDD 开发一个邮箱验证函数
第一轮:基本格式验证
我要用 TDD 方式开发一个 validateEmail 函数。
先帮我创建测试文件 src/utils/validate-email.test.ts,
写第一组测试:验证基本的邮箱格式。不要写实现代码。
Claude Code 会生成测试文件,包含几个基本用例(有效邮箱返回 true、没有 @ 返回 false、空字符串返回 false)。
测试失败了。创建实现文件,写最简单的代码让测试通过。
只写刚好够让测试通过的代码。
export function validateEmail(email: string): boolean {
if (!email) return false
return email.includes('@')
}
很粗糙——a@b 也会通过。但这正是 TDD 的精髓:先让测试绿了,后面再加测试来驱动更好的实现。
第二轮:更严格的格式校验
RED——加新测试:@ 后面必须有域名、域名必须包含点、拒绝多个 @。新测试失败。
GREEN——更新实现,拆分字符串检查各部分。全部通过。
REFACTOR——让 Claude Code 看看代码有没有可以改进的地方,改完跑测试确认。
第三轮:边界条件
加测试:邮箱前后有空格应该 trim、域名不能以点开头或结尾、local part 不能为空。
到这里你应该感受到了节奏:你只需要描述需求和边界,Claude Code 负责翻译成测试、写实现、验证结果。
封装 TDD Skill
创建 .claude/commands/tdd.md:
# TDD 工作流
按照 RED → GREEN → REFACTOR 循环推进开发。
## 规则
1. 永远先写测试,再写实现
2. 每一步都要跑测试,确认状态
3. GREEN 阶段只写让测试通过的最少代码
4. 每轮 GREEN 之后询问是否需要重构
5. 使用项目现有的测试框架
## 流程
### 启动
- 确认功能需求和测试文件路径
- 确认测试框架
### 循环
1. RED: 写测试 → 运行 → 确认失败
2. GREEN: 写最小实现 → 运行 → 确认通过
3. REFACTOR: 询问是否重构 → 重构 → 运行 → 确认通过
### 结束
用户说"结束"或功能完成时:
- 运行完整测试套件
- 输出覆盖率报告
## 当前任务
$ARGUMENTS
/tdd validateEmail 邮箱验证函数
适用场景
适合 TDD
纯逻辑函数——邮箱验证、价格计算、数据格式转换。输入明确、输出可预测,TDD 效率极高。
API 接口处理——请求参数校验、响应数据转换、错误码映射。边界条件多,TDD 能系统覆盖。
业务规则——"满 300 减 50,且不能和会员折扣叠加"。用测试用例表达比自然语言更清晰。
Bug 修复——先写复现 bug 的测试,再修复。既确认修好了,又防止回归。这可能是 TDD 性价比最高的场景。
不太适合 TDD
判断标准:如果这段代码会被长期维护,而且行为可以用"输入 → 输出"描述,TDD 大概率值得做。
实际经验
用 Claude Code + TDD 工作了一段时间的真实感受:
测试覆盖率上去了。 之前 40%-60%,用 TDD 的模块基本 90% 以上。不是刻意追求,而是 TDD 的自然结果——每一行代码都是为了让某个测试通过才写的。
重构变得不可怕了。 以前重构总有"走钢丝"的感觉。有了测试兜底,就变成了"大胆改,跑一下,绿了就没问题"。
和 Claude Code 配合的窍门:每轮只加 2-3 个测试。 一次给太多,AI 容易过度设计。少加几个,逼它写最小实现,后面再迭代。
不是所有代码都要 TDD。 核心业务逻辑用 TDD,工具函数用 TDD,API 参数校验用 TDD,其他正常开发后补测试。选择性使用效果最好。
下一篇讲多智能体编排——让多个 AI 角色像团队一样协作完成复杂任务。
本篇要点:
- TDD = 红绿重构循环,先写失败的测试,再写最小实现,最后重构
- Claude Code 接管了 TDD 中最烦人的部分——写测试、跑测试、分析报错
- 封装成
/tdd 命令,一键进入标准工作流
- 每轮只加 2-3 个测试,避免 AI 过度设计
- 选择性使用:纯逻辑函数和业务规则适合,UI 和原型不适合