5tldr 测试驱动开发 (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%但质量低
- 忽略边界条件
### ✅ 建议
- 严格遵循红-绿-重构
- 每个测试独立运行
- 测试公开接口和行为
- 关注有意义的覆盖率
- 覆盖边界和异常情况