---

name: test-driven-development description: 测试驱动开发，红-绿-重构循环 source: https://github.com/obra/superpowers

测试驱动开发 (TDD)

基于 obra/superpowers 的 TDD 方法论。

核心原则

先写测试，再写代码。红-绿-重构。

触发条件

当用户需要实现新功能、修复 Bug、或重构代码时激活。

TDD 循环

🔴 红：写失败的测试

1. 明确要实现的功能
2. 写一个测试用例
3. 运行测试，确认失败
4. 失败原因应该是功能未实现

🟢 绿：写最少的代码让测试通过

1. 只写让测试通过的代码
2. 不要过度设计
3. 不要写额外功能
4. 运行测试，确认通过

🔵 重构：改进代码质量

1. 在测试保护下重构
2. 消除重复代码
3. 改善命名和结构
4. 运行测试，确认仍然通过

工作流程

┌─────────────────────────────────────┐
│                                     │
│   ┌─────────┐                       │
│   │  🔴 红   │ ← 写失败的测试        │
│   └────┬────┘                       │
│        │                            │
│        ▼                            │
│   ┌─────────┐                       │
│   │  🟢 绿   │ ← 写最少代码通过测试   │
│   └────┬────┘                       │
│        │                            │
│        ▼                            │
│   ┌─────────┐                       │
│   │  🔵 重构 │ ← 改进代码质量        │
│   └────┬────┘                       │
│        │                            │
│        └────────────────────────────┘
│                  重复
└─────────────────────────────────────┘

输出格式

# 🧪 TDD 实现记录

## 功能需求
[需求描述]

## 实现计划
1. [ ] [测试用例1]
2. [ ] [测试用例2]
3. [ ] [测试用例3]

---

## 迭代1

### 🔴 红：测试用例
```[语言]
// 测试代码

运行结果：❌ 失败 失败原因：[原因]

🟢 绿：实现代码

// 实现代码

运行结果：✅ 通过

🔵 重构

[重构说明，如果有的话]

---

迭代2

[同上格式]

---

最终代码

测试文件

// 完整测试代码

实现文件

// 完整实现代码

测试覆盖

• 语句覆盖：X%
• 分支覆盖：X%
• 函数覆盖：X%

## 测试类型

### 单元测试

• 测试单个函数/方法
• 隔离外部依赖
• 快速执行
• 高覆盖率

### 集成测试

• 测试模块间交互
• 包含真实依赖
• 验证接口契约
• 中等执行速度

### 端到端测试

• 测试完整流程
• 模拟用户行为
• 验证业务场景
• 执行较慢

## 测试金字塔

    /\
   /  \
  / E2E \      ← 少量
 /──────\
/  集成   \    ← 适量

/──────────
/ 单元 \ ← 大量 /──────────────\

## 最佳实践

### 测试命名

// 格式：should_[预期行为]when[条件] test('should return empty array when input is empty') test('should throw error when user not found')

### 测试结构 (AAA)

// Arrange - 准备 const input = [1, 2, 3]

// Act - 执行 const result = sum(input)

// Assert - 断言 expect(result).toBe(6)

### FIRST 原则

F - Fast（快速） I - Independent（独立） R - Repeatable（可重复） S - Self-validating（自验证） T - Timely（及时）

## 常见陷阱

### ❌ 避免
- 先写代码再补测试
- 测试依赖执行顺序
- 测试实现细节而非行为
- 测试覆盖率追求100%但质量低
- 忽略边界条件

### ✅ 建议
- 严格遵循红-绿-重构
- 每个测试独立运行
- 测试公开接口和行为
- 关注有意义的覆盖率
- 覆盖边界和异常情况