---

name: test-driven-development description: "在编写实现代码之前，用于实现任何功能或修复任何缺陷" risk: unknown source: community date_added: "2026-02-27"

测试驱动开发（TDD）

概述

先写测试，看它失败，再写最少的代码让它通过。

核心原则： 如果你没有看到测试失败，你就不知道它是否测试了正确的东西。

违反规则的字面意思就是违反规则的精神。

何时使用

始终使用：

• 新功能
• 缺陷修复
• 重构
• 行为变更

例外情况（需询问你的搭档）：

• 一次性原型
• 生成的代码
• 配置文件

想着"就这一次跳过TDD"？停下来。那是自我合理化。

铁律

NO PRODUCTION CODE WITHOUT A FAILING TEST FIRST

在测试之前写了代码？删掉它。重新开始。

没有例外：

• 不要把它当作"参考"保留
• 不要在写测试时"改编"它
• 不要看它
• 删除就是删除

从测试出发重新实现。句号。

红-绿-重构

digraph tdd_cycle {
    rankdir=LR;
    red [label="RED\nWrite failing test", shape=box, style=filled, fillcolor="#ffcccc"];
    verify_red [label="Verify fails\ncorrectly", shape=diamond];
    green [label="GREEN\nMinimal code", shape=box, style=filled, fillcolor="#ccffcc"];
    verify_green [label="Verify passes\nAll green", shape=diamond];
    refactor [label="REFACTOR\nClean up", shape=box, style=filled, fillcolor="#ccccff"];
    next [label="Next", shape=ellipse];

    red -> verify_red;
    verify_red -> green [label="yes"];
    verify_red -> red [label="wrong\nfailure"];
    green -> verify_green;
    verify_green -> refactor [label="yes"];
    verify_green -> green [label="no"];
    refactor -> verify_green [label="stay\ngreen"];
    verify_green -> next;
    next -> red;
}

红色 - 编写失败的测试

编写一个最小的测试，展示期望的行为。

<Good> ```typescript test('retries failed operations 3 times', async () => { let attempts = 0; const operation = () => { attempts++; if (attempts < 3) throw new Error('fail'); return 'success'; };

const result = await retryOperation(operation);

expect(result).toBe('success'); expect(attempts).toBe(3); });

名称清晰，测试真实行为，只测一件事
</Good>

<Bad>
```typescript
test('retry works', async () => {
  const mock = jest.fn()
    .mockRejectedValueOnce(new Error())
    .mockRejectedValueOnce(new Error())
    .mockResolvedValueOnce('success');
  await retryOperation(mock);
  expect(mock).toHaveBeenCalledTimes(3);
});

名称模糊，测试的是mock而非代码 </Bad>

要求：

• 一个行为
• 清晰的名称
• 真实代码（除非不可避免，否则不用mock）

验证红色 - 观察失败

必须执行。绝不跳过。

npm test path/to/test.test.ts

确认：

• 测试失败（不是报错）
• 失败信息符合预期
• 因功能缺失而失败（不是拼写错误）

测试通过了？ 你在测试已有行为。修改测试。

测试报错了？ 修复错误，重新运行直到正确失败。

绿色 - 最少代码

编写能让测试通过的最简代码。

<Good> ```typescript async function retryOperation<T>(fn: () => Promise<T>): Promise<T> { for (let i = 0; i < 3; i++) { try { return await fn(); } catch (e) { if (i === 2) throw e; } } throw new Error('unreachable'); } ``` 刚好够通过 </Good> <Bad> ```typescript async function retryOperation<T>( fn: () => Promise<T>, options?: { maxRetries?: number; backoff?: 'linear' | 'exponential'; onRetry?: (attempt: number) => void; } ): Promise<T> { // YAGNI } ``` 过度设计 </Bad>

不要添加功能、重构其他代码，或做超出测试范围的"改进"。

验证绿色 - 观察通过

必须执行。

npm test path/to/test.test.ts

确认：

• 测试通过
• 其他测试仍然通过
• 输出干净（无错误、无警告）

测试失败了？ 修改代码，不是测试。

其他测试失败了？ 立即修复。

重构 - 清理代码

仅在绿色之后：

• 消除重复
• 改善命名
• 提取辅助函数

保持测试绿色。不要添加行为。

循环

为下一个功能编写下一个失败的测试。

好的测试

| 质量 | 好的 | 差的 | |------|------|------| | 最小化 | 只测一件事。名称中有"和"？拆分它。 | test('validates email and domain and whitespace') | | 清晰 | 名称描述行为 | test('test1') | | 展示意图 | 展示期望的API | 模糊了代码应该做什么 |

为什么顺序很重要

"我之后写测试来验证它能工作"

代码之后写的测试会立即通过。立即通过什么也证明不了：

• 可能测试了错误的东西
• 可能测试了实现而非行为
• 可能遗漏了你忘记的边界情况
• 你从未看到它捕获到缺陷

先写测试迫使你看到测试失败，证明它确实在测试某些东西。

"我已经手动测试了所有边界情况"

手动测试是临时性的。你以为测试了所有情况，但实际上：

• 没有记录