test-driven-development

测试驱动开发

概览

在写让它通过的代码之前，先写一个失败的测试。对 bug 修复来说，也是在尝试修复前先用测试复现 bug。测试就是证据，“看起来对”不算完成。有高质量测试的代码库，是 AI agent 的超能力；没有测试的代码库，则是一种负担。

何时使用

• 实现任何新的逻辑或行为
• 修复任何 bug，也就是 Prove-It Pattern
• 修改现有功能
• 增加边界情况处理
• 任何可能破坏现有行为的改动

不适用的场景： 纯配置改动、文档更新，或不会影响行为的静态内容修改。

相关 skill： 对浏览器端改动，应把 TDD 和 Chrome DevTools MCP 的运行时验证结合起来，见下方 Browser Testing 部分。

TDD 循环

    RED                GREEN              REFACTOR
 Write a test    Write minimal code    Clean up the
 that fails  ──→  to make it pass  ──→  implementation  ──→  (repeat)
      │                  │                    │
      ▼                  ▼                    ▼
   Test FAILS        Test PASSES         Tests still PASS

步骤 1：RED，先写一个失败测试

先写测试，而且它必须失败。一个一开始就通过的测试，证明不了任何事情。

// RED: This test fails because createTask doesn't exist yet
describe('TaskService', () => {
  it('creates a task with title and default status', async () => {
    const task = await taskService.createTask({ title: 'Buy groceries' });

    expect(task.id).toBeDefined();
    expect(task.title).toBe('Buy groceries');
    expect(task.status).toBe('pending');
    expect(task.createdAt).toBeInstanceOf(Date);
  });
});

步骤 2：GREEN，让它刚好通过

写出能让测试通过的最少代码，不要过度设计：

// GREEN: Minimal implementation
export async function createTask(input: { title: string }): Promise<Task> {
  const task = {
    id: generateId(),
    title: input.title,
    status: 'pending' as const,
    createdAt: new Date(),
  };
  await db.tasks.insert(task);
  return task;
}

步骤 3：REFACTOR，整理实现

当测试已经是绿色时，再在不改变行为的前提下优化代码：

• 提取共享逻辑
• 改善命名
• 去重
• 必要时做性能优化

每做一步重构，都重新跑测试，确认没有破坏行为。

举证模式（Prove-It Pattern，Bug 修复）

当收到 bug 报告时，不要一上来就修。 先写一个能复现它的测试。

Bug report arrives
       │
       ▼
  Write a test that demonstrates the bug
       │
       ▼
  Test FAILS (confirming the bug exists)
       │
       ▼
  Implement the fix
       │
       ▼
  Test PASSES (proving the fix works)
       │
       ▼
  Run full test suite (no regressions)