shared/tdd

测试驱动开发（TDD）

核心铁律

没有失败的测试，就不写生产代码。

如果先写了实现代码，必须删除，从测试重新开始。不保留"参考"，不"边写测试边改"。

适用场景

必须使用 TDD：

• 新功能实现
• Bug 修复
• 代码重构
• 任何行为变更

例外（需用户明确同意）：

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

Red-Green-Refactor 循环

🔴 RED — 写失败测试

为一个行为写最小测试：

• 一个测试只测一件事（名称里有 "and" 就拆开）
• 名称描述行为，而非实现（rejects empty email 而非 test1）
• 用真实代码，除非依赖外部服务才 mock
• 展示你期望的 API 长什么样

// ✅ 好：测试真实行为
test('rejects empty email', () => {
  expect(validateEmail('')).toBe(false);
});

// ❌ 坏：测试 mock 而非代码
test('email works', () => {
  const mock = jest.fn();
  mock('');
  expect(mock).toHaveBeenCalled();
});

验证 RED — 必须看到它失败

这一步不可跳过。 运行测试，确认：

# 前端
npx jest path/to/test.test.ts
# 后端
npm test -- path/to/test.test.ts

确认三件事：

1. 测试失败（不是通过）
2. 失败原因是功能缺失（不是拼写错误、导入错误）
3. 失败信息符合预期

如果测试直接通过 → 你在测已有行为，测试写错了，修正它。 如果测试报错（error） → 修复错误（如导入路径），重跑直到它正确失败。

🟢 GREEN — 写最小实现

写刚好让测试通过的最少代码：

• 不添加测试未要求的功能
• 不重构、不"顺便优化"
• 不提前抽象

// ✅ 好：刚好通过
function validateEmail(email: string): boolean {
  return email.trim().length > 0;
}

// ❌ 坏：过度工程
function validateEmail(
  email: string,
  options?: { allowPlus?: boolean; domainWhitelist?: string[] },
): boolean {
  // YAGNI
}

验证 GREEN — 必须看到它通过

运行测试，确认：

1. 新测试通过
2. 所有已有测试仍然通过
3. 输出干净（无报错、无意外警告）

如果新测试失败 → 修代码，不修测试。 如果其他测试失败 → 立即修复。

🔵 REFACTOR — 重构（仅在 GREEN 之后）

测试全绿后才允许重构：

• 消除重复
• 改善命名
• 提取辅助函数
• 不新增行为

重构后必须重新跑全部测试，保持全绿。

循环

下一个行为 → 回到 RED。

Bug 修复 TDD

修复 bug 时，先写一个复现 bug 的失败测试：

1. 写测试复现 bug → 确认失败（RED）
2. 修复代码 → 确认通过（GREEN）
3. 这个测试就是回归保护

禁止在没有复现测试的情况下修复 bug。

验证清单

标记任务完成前，逐项确认：

• 每个新增函数/方法都有对应测试
• 每个测试都先看到它失败（RED 已验证）
• 失败原因是功能缺失，而非拼写/导入错误
• 实现代码是让测试通过的最小集
• 全部测试通过
• 测试用真实代码（仅在不可避免时 mock）
• 边界条件和错误路径已覆盖

任何一项打不了勾 → 你跳过了 TDD，回到 RED 重新开始。

常见借口与回应

借口	回应
"太简单了不用测"	简单代码也会坏，测试只要 30 秒
"我之后补测试"	事后写的测试一跑就过，证明不了任何事
"我手动测过了"	手动测试无记录、不可复跑、容易漏
"已经写了代码，删了浪费"	沉没成本。保留未验证的代码才是技术债
"TDD 太慢"	TDD 比事后调试快，省的是未来的时间
"这个不一样因为..."	没有例外。删代码，从测试开始。