# Tdd Workflow

> TDD（测试驱动开发）工作流原则。红-绿-重构循环。

- Skill: `misonl/tdd-workflow` (Agent Skill)
- Install (CLI): `npx skillmds@latest add misonl/tdd-workflow`
- Raw SKILL.md: https://api.skillmd.com/api/skills/misonl/tdd-workflow/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Productivity
- Author: misonl (https://skillmd.com/u/misonl)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/misonl/tdd-workflow

---


# 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） |

---

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