⚡

测试驱动开发 test-driven-development

测试驱动开发（TDD）是一种软件开发方法，强调先编写测试代码，再编写生产代码，以确保代码质量并促进开发效率。

测试 0 次安装 0 次浏览 更新于 3/4/2026

name: test-driven-development description: 使用任何特性或修复bug之前，先编写测试代码

测试驱动开发 (TDD)

概览

先写测试。观察它失败。写最少的代码使其通过。

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

违反规则的文字就是违反规则的精神。

何时使用

总是：

  • 新特性
  • 修复bug
  • 重构
  • 行为变更

例外（询问你的人类伙伴）：

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

想要“这次跳过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="Next", 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 - 写失败的测试

写一个最小的测试显示应该发生什么。

<Good>

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>

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

名称模糊，测试模拟而不是代码 </Bad>

要求：

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

Verify RED - 观察它失败

强制性。绝不要跳过。

npm test path/to/test.test.ts

确认：

  • 测试失败（不是错误）
  • 失败信息是预期的
  • 因为缺少功能而失败（不是因为拼写错误）

**测试通过了？**你在测试已有的行为。修正测试。

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

GREEN - 最小代码

写最简单的代码使测试通过。

<Good>

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>

async function retryOperation<T>(
  fn: () => Promise<T>,
  options?: {
    maxRetries?: number;
    backoff?: 'linear' | 'exponential';
    onRetry?: (attempt: number) => void;
  }
): Promise<T> {
  // YAGNI
}

过度工程化 </Bad>

不要添加功能，重构其他代码，或“改进”超出测试范围。

Verify GREEN - 观察它通过

强制性。

npm test path/to/test.test.ts

确认：

  • 测试通过
  • 其他测试仍然通过
  • 输出纯净（没有错误，警告）

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

**其他测试失败了？**现在就修正。

REFACTOR - 清理

只有在绿色之后：

  • 移除重复
  • 改善名称
  • 提取助手

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

重复

下一个失败的测试用于下一个特性。

好的测试

质量 好的 坏的
最小 一件事情。名称中有“和”？分开它。 test('validates email and domain and whitespace')
清晰 名称描述行为 test('test1')
显示意图 展示期望的API 掩盖代码应该做什么

为什么顺序重要

“我会在代码后写测试来验证它是否工作”

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

  • 可能测试错了事情
  • 可能测试了实现，而不是行为
  • 可能错过了你忘记的边缘情况
  • 你从未看到它捕获bug

测试先行迫使你看到测试失败，证明它实际上测试了某些东西。

“我已经手动测试了所有边缘情况”

手动测试是临时的。你以为你测试了一切，但是：

  • 没有你测试什么的记录
  • 代码变化时不能重新运行
  • 在压力下容易忘记案例
  • “它在我尝试时工作” ≠ 全面

自动化测试是系统的。它们每次都以相同的方式运行。

“删除X小时的工作是浪费”

沉没成本谬误。时间已经过去了。你现在的选择：

  • 删除并用TDD重写（X更多小时，高信心）
  • 保留它并在之后添加测试（30分钟，低信心，可能的bug）

“浪费”是保留你不能信任的代码。没有真正测试的工作代码是技术债务。

“TDD是教条的，实用主义意味着适应”

TDD是实用的：

  • 在提交前发现bug（比调试后快）
  • 防止回归（测试立即捕捉破坏）
  • 文档化行为（测试显示如何使用代码）
  • 使重构成为可能（自由更改，测试捕捉破坏）

“实用”的捷径 = 在生产中调试 = 更慢。

“测试后达到相同的目标 - 它是精神不是仪式”

不。测试后回答“这个做什么？”测试先行回答“这个应该做什么？”

测试后受你的实现偏见。你测试了你建造的东西，而不是所需的。你验证你记住的边缘情况，而不是发现的。

测试先行迫使在实现之前发现边缘情况。测试后验证你记住了一切（你没有）。

30分钟的测试后 ≠ TDD。你有覆盖率，失去了测试工作的证明。

常见理由

借口 现实
“太简单，无法测试” 简单的代码会坏。测试需要30秒。
“我会之后测试” 测试立即通过证明不了什么。
“测试后达到相同的目标” 测试后 = “这个做什么？”测试先行 = “这个应该做什么？”
“已经手动测试过了” 临时 ≠ 系统。没有记录，不能重新运行。
“删除X小时是浪费” 沉没成本谬误。保留未经验证的代码是技术债务。
“保留作为参考，首先写测试” 你会适应它。那是测试后。删除意味着删除。
“需要先探索” 好的。扔掉探索，从TDD开始。
“测试难 = 设计不清楚” 听测试的。测试难 = 使用难。
“TDD会让我慢下来” TDD比调试快。实用 = 测试先行。
“手动测试更快” 手动测试不能证明边缘情况。你会重新测试每次更改。
“现有代码没有测试” 你在改进它。为现有代码添加测试。

红旗 - 停止并重新开始

  • 代码在测试之前
  • 实现后测试
  • 测试立即通过
  • 不能解释为什么测试失败
  • “之后”添加测试
  • 合理化“就这一次”
  • “我已经手动测试过了”
  • “测试后达到相同的目标”
  • “它是关于精神不是仪式”
  • “保留作为参考”或“适应现有代码”
  • “已经花了X小时，删除是浪费”
  • “TDD是教条的，我是实用主义”
  • “这是不同的，因为…”

所有这些都意味着：删除代码。用TDD重新开始。

示例：Bug修复

Bug： 接受空电子邮件

RED

test('rejects empty email', async () => {
  const result = await submitForm({ email: '' });
  expect(result.error).toBe('Email required');
});

Verify RED

$ npm test
FAIL: expected 'Email required', got undefined

GREEN

function submitForm(data: FormData) {
  if (!data.email?.trim()) {
    return { error: 'Email required' };
  }
  // ...
}

Verify GREEN

$ npm test
PASS

REFACTOR 如果需要，提取多个字段的验证。

验证清单

在标记工作完成之前：

  • [ ] 每个新函数/方法都有测试
  • [ ] 在实现之前观察每个测试失败
  • [ ] 每个测试失败的原因是预期的（缺少功能，不是拼写错误）
  • [ ] 为每个测试编写了最小代码
  • [ ] 所有测试通过
  • [ ] 输出纯净（没有错误，警告）
  • [ ] 测试使用真实代码（模拟只有在不可避免时才使用）
  • [ ] 覆盖边缘情况和错误

不能检查所有复选框？你跳过了TDD。重新开始。

卡住时

问题 解决方案
不知道如何测试 写下期望的API。先写断言。询问你的人类伙伴。
测试太复杂 设计太复杂。简化接口。
必须模拟一切 代码太耦合。使用依赖注入。
测试设置巨大 提取助手。仍然复杂？简化设计。

集成调试

发现bug？编写失败的测试来重现它。遵循TDD周期。测试证明修复并防止回归。

绝不在没有测试的情况下修复bug。

测试反模式

添加模拟或测试工具时，阅读@testing-anti-patterns.md以避免常见陷阱：

  • 测试模拟行为而不是真实行为
  • 在生产类中添加测试专用方法
  • 不理解依赖的情况下进行模拟

最终规则

生产代码 → 测试存在并且首先失败
否则 → 不是TDD

没有你的人类伙伴的许可，没有例外。