Test Driven Development

Test-Driven Development - 测试驱动开发

来源: obra/superpowers (142K⭐) - AI辅助开发方法论框架

参考: TDD (Test-Driven Development) 最佳实践

核心理念

"写测试不是为了证明代码正确，而是为了发现代码可能存在的错误。" —— 测试即文档

TDD三定律：

1. 除非是为了让一个失败的单元测试通过，否则不允许编写任何产品代码
2. 允许编写任何能够确保失败但无法编译的程序代码（逐步完善）
3. 允许编写刚好能够使失败测试通过的产品代码（不再多写）

红-绿-重构循环

    ┌─────────────────────────────────────┐
    │                                     │
    ▼                                     │
┌─────────┐   Write   ┌─────────┐   Fix   │
│  RED    │ ────────▶ │  GREEN  │ ───────▶│
│  失败   │   测试    │  通过   │   代码  │
└─────────┘           └─────────┘          │
    ▲                                        │
    │                                        │
    └──────────── Refactor ─────────────────┘
                  重构改进

🔴 RED 阶段：写一个会失败的测试

目标：描述期望的行为

操作：

1. 理解需求，写出期望的测试用例
2. 测试要尽可能小，只测一个方面
3. 运行测试，确认失败（这是预期的）

示例：

// ❌ 这会编译失败或测试失败
@Test
void shouldReturnEmptyListWhenNoData() {
    // 假设我们要实现：没有数据时返回空列表
    List<User> users = userService.findAll();
    assertTrue(users.isEmpty());
}

🟢 GREEN 阶段：写能让测试通过的最少代码

目标：快速让测试通过

操作：

1. 写最简单能通过的实现
2. 不要优化、不要完善——后续重构阶段再做
3. 测试通过即可停止

示例：

// ✅ 最简单的实现
public List<User> findAll() {
    return new ArrayList<>(); // 直接返回空列表
}

🔵 REFACTOR 阶段：重构改进

目标：消除重复、提升代码质量

操作：

1. 审视代码，寻找坏味道
2. 逐步重构，每次确保测试通过
3. 重构后测试仍要全部通过

示例：

// 重构：移除重复，改进设计
public List<User> findAll() {
    return userRepository.findAll(); // 真实实现
}

适用场景

测试用例设计

好的测试特点 (F.I.R.S.T)

测试命名规范

// 格式：[方法]_[场景]_[期望结果]
@Test
void shouldReturnEmptyListWhenNoDataExists()

@Test  
void shouldThrowExceptionWhenUserNotFound()

@Test
void shouldCalculateTotalPriceWithDiscount()

测试结构 (AAA模式)

@Test
void shouldProcessOrderCorrectly() {
    // Arrange - 准备测试数据
    Order order = new Order();
    order.addItem(new Item("Product", 100));
    
    // Act - 执行被测操作
    double total = orderProcessor.calculateTotal(order);
    
    // Assert - 验证结果
    assertEquals(100, total, 0.01);
}

常见测试覆盖点

测试金字塔

           ┌─────────┐
           │   E2E   │   ← 少量，端到端
          ┌─────────┐
         │集成测试 │   ← 中量，按模块
        ┌─────────┐
       │ 单元测试 │   ← 大量，最快最便宜
      └─────────┘

回归测试策略

修改代码后，确保：

1. 所有现有测试仍然通过
2. 新功能有测试覆盖
3. Bug修复有测试防止复现

# 运行所有测试
npm test

# 运行特定测试
npm test -- --grep "UserService"

# 生成覆盖率报告
npm test -- --coverage

输出模板

## TDD开发记录

### 功能：[功能名称]

#### 🔴 RED - 失败的测试
```java
[测试代码]

🟢 GREEN - 通过的实现

[实现代码]

🔵 REFACTOR - 重构

[重构后的代码]

测试覆盖

运行结果

✅ 12 tests passed
⏱️ 0.5s
📊 85% coverage

## 反模式警示

❌ **不要**：
- 先写代码后写测试（事后诸葛亮）
- 测试覆盖所有路径（聚焦关键逻辑）
- 测试依赖实现细节（测试行为非实现）
- 测试之间互相依赖（保持独立）
- 忽略失败的测试（失败即停）

✅ **应该**：
- 测试业务价值，而非技术细节
- 最小化设置代码
- 一个测试一个断言
- 让测试描述文档化