
关于
在实现任何功能或修复 Bug 时使用,在编写实现代码之前。
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 | 模糊了代码应该做什么 |
为什么顺序很重要
"我之后写测试来验证它能工作"
代码之后写的测试会立即通过。立即通过什么也证明不了:
- 可能测试了错误的东西
- 可能测试了实现而非行为
- 可能遗漏了你忘记的边界情况
- 你从未看到它捕获到缺陷
先写测试迫使你看到测试失败,证明它确实在测试某些东西。
"我已经手动测试了所有边界情况"
手动测试是临时性的。你以为测试了所有情况,但实际上:
- 没有记录

