name: 测试驱动开发 description: 在实现任何功能或修复错误之前使用，先写实现代码
测试驱动开发 (TDD)
概述
先写测试。看它失败。写最少代码通过。
核心原则： 如果你没有看测试失败，你不知道它测试的是否正确。
违反规则的文字就是违反规则的精神。
何时使用
总是：
- 新功能
- 错误修复
- 重构
- 行为变更
例外（询问你的人类伙伴）：
- 一次性原型
- 生成的代码
- 配置文件
想“跳过TDD就这一次”？停止。那是合理化。
铁律
没有生产代码在没有失败的测试之前
在测试之前写代码？删除它。重新开始。
没有例外：
- 不要保留它作为“参考”
- 不要在写测试时“调整”它
- 不要看它
- 删除意味着删除
从测试重新实现。结束。
红-绿-重构
digraph tdd_cycle {
rankdir=LR;
red [label="RED
写失败测试", shape=box, style=filled, fillcolor="#ffcccc"];
verify_red [label="验证失败
正确", shape=diamond];
green [label="GREEN
最少代码", shape=box, style=filled, fillcolor="#ccffcc"];
verify_green [label="验证通过
所有绿", shape=diamond];
refactor [label="REFACTOR
清理", shape=box, style=filled, fillcolor="#ccccff"];
next [label="下一步", shape=ellipse];
red -> verify_red;
verify_red -> green [label="是"];
verify_red -> red [label="错误
失败"];
green -> verify_green;
verify_green -> refactor [label="是"];
verify_green -> green [label="否"];
refactor -> verify_green [label="保持
绿"];
verify_green -> next;
next -> red;
}
RED - 写失败测试
写一个最小的测试显示应该发生什么。
<好>
test('重试失败操作3次', async () => {
let attempts = 0;
const operation = () => {
attempts++;
if (attempts < 3) throw new Error('失败');
return '成功';
};
const result = await retryOperation(operation);
expect(result).toBe('成功');
expect(attempts).toBe(3);
});
清晰名字，测试真实行为，一件事 </好>
<坏>
test('重试工作', async () => {
const mock = jest.fn()
.mockRejectedValueOnce(new Error())
.mockRejectedValueOnce(new Error())
.mockResolvedValueOnce('成功');
await retryOperation(mock);
expect(mock).toHaveBeenCalledTimes(3);
});
模糊名字，测试模拟不是代码 </坏>
要求：
- 一个行为
- 清晰名字
- 真实代码（除非不可避免，不要用模拟）
验证 RED - 看它失败
强制。永远不要跳过。
npm test path/to/test.test.ts
确认：
- 测试失败（不是错误）
- 失败消息是预期的
- 失败因为功能缺失（不是打字错误）
测试通过？ 你在测试现有行为。修复测试。
测试错误？ 修复错误，重新运行直到正确失败。
GREEN - 最少代码
写最简单的代码通过测试。
<好>
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('不可达');
}
刚好足够通过 </好>
<坏>
async function retryOperation<T>(
fn: () => Promise<T>,
options?: {
maxRetries?: number;
backoff?: '线性' | '指数';
onRetry?: (attempt: number) => void;
}
): Promise<T> {
// YAGNI
}
过度工程 </坏>
不要添加功能、重构其他代码，或“改进”超越测试。
验证 GREEN - 看它通过
强制。
npm test path/to/test.test.ts
确认：
- 测试通过
- 其他测试仍然通过
- 输出纯净（没有错误，警告）
测试失败？ 修复代码，不是测试。
其他测试失败？ 现在修复。
REFACTOR - 清理
只有在绿之后：
- 移除重复
- 改进名字
- 提取助手
保持测试绿。不要添加行为。
重复
下一个失败测试为下一个功能。
好测试
| 质量 | 好 | 坏 |
|---|---|---|
| 最小 | 一件事。名字中有“和”？拆分它。 | test('验证邮箱和域名和空格') |
| 清晰 | 名字描述行为 | test('测试1') |
| 显示意图 | 展示期望的API | 隐藏代码应该做什么 |
为什么顺序重要
“我会之后写测试来验证它工作”
测试在代码后写立即通过。立即通过证明不了什么：
- 可能测试错误的东西
- 可能测试实现，不是行为
- 可能错过你忘记的边缘情况
- 你从未看到它捕获错误
测试先强制你看测试失败，证明它实际测试了东西。
“我已经手动测试了所有边缘情况”
手动测试是临时性的。你以为你测试了所有但：
- 没有记录你测试了什么
- 当代码变化时不能重新运行
- 在压力下容易忘记情况
- “我试的时候工作” ≠ 全面
自动化测试是系统性的。它们每次以相同方式运行。
“删除X小时的工作是浪费”
沉没成本谬误。时间已经过去。你现在的选择：
- 删除并用TDD重写（X更多小时，高置信度）
- 保留它并在之后添加测试（30分钟，低置信度，可能错误）
“浪费”是保留你不能信任的代码。没有真实测试的工作代码是技术债务。
“TDD是教条主义，实用主义意味着适应”
TDD是实用主义：
- 在提交前发现错误（比之后调试更快）
- 防止回归（测试立即捕获中断）
- 记录行为（测试展示如何使用代码）
- 启用重构（自由更改，测试捕获中断）
“实用主义”捷径 = 在生产中调试 = 更慢。
“之后测试达到相同目标 - 是精神不是仪式”
不。之后测试回答“这是什么做的？” 测试先回答“这应该做什么？”
之后测试受你的实现偏见。你测试你构建的，不是需要的。你验证记住的边缘情况，不是发现的。
测试先强制边缘情况发现在实现之前。之后测试验证你记住了一切（你没有）。
30分钟的之后测试 ≠ TDD。你获得覆盖率，失去测试工作的证明。
常见合理化
| 借口 | 现实 |
|---|---|
| “太简单测试” | 简单代码会坏。测试取30秒。 |
| “我会之后测试” | 测试立即通过证明不了什么。 |
| “之后测试达到相同目标” | 之后测试 = “这是什么做的？” 测试先 = “这应该做什么？” |
| “已经手动测试” | 临时 ≠ 系统性。没有记录，不能重新运行。 |
| “删除X小时是浪费” | 沉没成本谬误。保留未验证代码是技术债务。 |
| “保留为参考，先写测试” | 你会调整它。那是之后测试。删除意味着删除。 |
| “需要先探索” | 好。扔掉探索，用TDD开始。 |
| “测试难 = 设计不清晰” | 听测试。测试难 = 使用难。 |
| “TDD会减慢我” | TDD比调试快。实用主义 = 测试先。 |
| “手动测试更快” | 手动不证明边缘情况。你会重新测试每个更改。 |
| “现有代码没有测试” | 你在改进它。为现有代码添加测试。 |
红旗 - 停止并重新开始
- 代码在测试之前
- 测试在实现之后
- 测试立即通过
- 不能解释为什么测试失败
- 测试“之后”添加
- 合理化“就这一次”
- “我已经手动测试它”
- “之后测试达到相同目的”
- “是精神不是仪式”
- “保留为参考”或“调整现有代码”
- “已经花了X小时，删除是浪费”
- “TDD是教条主义，我是实用主义”
- “这不同因为…”
所有这些意味着：删除代码。用TDD重新开始。
例子：错误修复
错误： 空邮箱被接受
RED
test('拒绝空邮箱', async () => {
const result = await submitForm({ email: '' });
expect(result.error).toBe('邮箱必需');
});
验证 RED
$ npm test
FAIL: 预期 '邮箱必需', 得到 undefined
GREEN
function submitForm(data: FormData) {
if (!data.email?.trim()) {
return { error: '邮箱必需' };
}
// ...
}
验证 GREEN
$ npm test
PASS
REFACTOR 如果需要，提取验证为多字段。
验证清单
在标记工作完成之前：
- [ ] 每个新函数/方法有测试
- [ ] 在实现之前看每个测试失败
- [ ] 每个测试因预期原因失败（功能缺失，不是打字错误）
- [ ] 写最少代码通过每个测试
- [ ] 所有测试通过
- [ ] 输出纯净（没有错误，警告）
- [ ] 测试使用真实代码（只在不可避免时用模拟）
- [ ] 覆盖边缘情况和错误
不能勾选所有框？你跳过了TDD。重新开始。
当卡住时
| 问题 | 解决方案 |
|---|---|
| 不知道如何测试 | 写希望的API。先写断言。询问你的人类伙伴。 |
| 测试太复杂 | 设计太复杂。简化接口。 |
| 必须模拟所有 | 代码太耦合。使用依赖注入。 |
| 测试设置巨大 | 提取助手。仍然复杂？简化设计。 |
调试集成
发现错误？写失败测试复制它。遵循TDD周期。测试证明修复并防止回归。
永远不修复错误没有测试。
测试反模式
当添加模拟或测试实用程序时，阅读@testing-anti-patterns.md以避免常见陷阱：
- 测试模拟行为而不是真实行为
- 添加测试专用方法到生产类
- 模拟没有理解依赖
最终规则
生产代码 → 测试存在并先失败
否则 → 不是TDD
没有你人类伙伴的许可，没有例外。