tdd-workflow

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 三大法则

1. 除非是为了使一个失败的单元测试通过，否则不允许编写任何生产代码。
2. 只允许编写刚好能够证明失败的测试（编译失败也算失败）。
3. 只允许编写刚好能够使当前失败测试通过的生产代码。

---

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）

---

记住： 测试就是规格。如果你写不出测试，说明你还没有真正理解需求。