| name | tdd-workflow |
| description | TDD(测试驱动开发)工作流原则。红-绿-重构循环。 |
| allowed-tools | Read, Write, Edit, Glob, Grep, Bash |
TDD(测试驱动开发)工作流
先写测试,后写代码。
1. TDD 核心循环
[CRITICAL] 红(RED)-> 编写一个失败的测试
v
[NIT] 绿(GREEN)-> 编写最少量的代码使测试通过
v
重构(REFACTOR)-> 优化代码结构与质量
v
循环往复...
2. TDD 三大法则
- 除非是为了使一个失败的单元测试通过,否则不允许编写任何生产代码。
- 只允许编写刚好能够证明失败的测试(编译失败也算失败)。
- 只允许编写刚好能够使当前失败测试通过的生产代码。
3. “红(RED)”阶段准则
编写重点
| 关注点 | 示例 |
|---|
| Behavior(行为) | “应当能够相加两个数字” |
| Edge Cases(边缘情况) | “应当能够处理空输入” |
| 错误状态 | “遇到无效数据时应当抛出异常” |
“红”阶段规则
- 测试必须先失败。
- 测试名称应清晰描述预期的行为。
- 每个测试(最好)仅包含一个 Assertion(断言)。
4. “绿(GREEN)”阶段准则
最少代码原则
| 原则 | 含义 |
|---|
| YAGNI | You Aren't Gonna Need It(你不会需要它) |
| 最简方案 | 编写能让测试通过的最少代码 |
| 暂不优化 | 此时只求“跑通”,不求“精炼” |
“绿”阶段规则
- 不要编写多余的代码。
- 暂时不要进行性能优化。
- 仅仅是为了通过测试,不多做一点。
5. “重构(REFACTOR)”阶段准则
优化方向
| 领域 | 动作 |
|---|
| 重复逻辑 | 提取公共函数/代码块 |
| 命名规范 | 使代码意图更加清晰 |
| 代码结构 | 改善组织架构 |
| 复杂度 | 简化逻辑判断 |
重构规则
- 所有测试必须保持绿色。
- 采取小步快跑的增量式改动。
- 每次重构之后都进行 Commit(提交)。
6. AAA 模式
每个测试均应遵循 AAA(Arrange-Act-Assert,准备-执行-断言):
| 步骤 | 目的 |
|---|
| Arrange(准备) | 初始化测试数据与环境 |
| Act(执行) | 执行被测代码逻辑 |
| Assert(断言) | 验证结果是否符合预期 |
7. 何时使用 TDD
| 场景 | TDD 价值 |
|---|
| 新功能开发 | 极高 |
| Bug(缺陷)修复 | 极高(先写复现测试) |
| 复杂逻辑实现 | 极高 |
| Spike(探索性研究) | 较低(研究完后再补 TDD) |
| UI(用户界面)布局调试 | 较低 |
8. 测试优先级
| 优先级 | 测试类型 |
|---|
| 1 | Happy path(正常路径) |
| 2 | Error cases(错误处理) |
| 3 | Edge cases(边界情况) |
| 4 | Performance(性能) |
9. 应避免的反模式
| [FAIL] 禁止(Don't) | [OK] 推荐(Do) |
|---|
| 跳过“红”阶段直接写代码 | 亲眼见证测试失败后再写代码 |
| 先写代码后补测试 | 先写测试作为规格说明 |
| 初期就进行过度工程 | 保持简单,仅满足当前测试 |
| 一个测试包含过多断言 | 每个测试仅验证一个行为 |
| 测试内部实现细节 | 测试对外的行为表现 |
10. AI 增强型 TDD 协作模式
Multi-Agent(多智能体)编排视角
| Agent | 角色 |
|---|
| Agent A | 编写失败测试(RED) |
| Agent B | 编写实现使其通过(GREEN) |
| Agent C | 进行优化(REFACTOR) |
记住: 测试就是规格。如果你写不出测试,说明你还没有真正理解需求。