⚡

测试驱动开发Skill test-driven-development

测试驱动开发（TDD）是一种软件开发实践，强调先编写测试用例，再编写实现代码，通过“红-绿-重构”循环提升代码质量和测试覆盖率。适用于新功能、错误修复、重构等场景，确保代码可靠性和可维护性。关键词：测试驱动开发、TDD、软件开发、测试、代码质量、重构、自动化测试、红绿重构、敏捷开发、单元测试、行为驱动开发。

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

name: 测试驱动开发 description: 在编写实现代码之前，实施任何功能或错误修复时使用

测试驱动开发（TDD）

概述

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

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

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

何时使用

总是：

  • 新功能
  • 错误修复
  • 重构
  • 行为变更

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

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

想“这次就跳过TDD”吗？停止。那是合理化。

铁律

没有失败测试之前，不得编写生产代码

先写代码再写测试？删除它。从头开始。

没有例外：

  • 不要保留它作为“参考”
  • 不要编写测试时“适应”它
  • 不要看它
  • 删除意味着删除

从测试开始全新实现。就这样。

红-绿-重构

digraph tdd_cycle {
    rankdir=LR;
    red [label="红
编写失败测试", shape=box, style=filled, fillcolor="#ffcccc"];
    verify_red [label="验证失败
正确", shape=diamond];
    green [label="绿
最少代码", shape=box, style=filled, fillcolor="#ccffcc"];
    verify_green [label="验证通过
全绿", shape=diamond];
    refactor [label="重构
清理", 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;
}

红 - 编写失败测试

编写一个最小的测试，展示应该发生的事情。

<好>

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);
});

模糊名称，测试模拟而非代码 </坏>

要求：

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

验证红 - 观察失败

强制。永不跳过。

npm test 路径/到/测试.test.ts

确认：

  • 测试失败（而非错误）
  • 失败消息符合预期
  • 失败是因为功能缺失（而非拼写错误）

测试通过？ 你在测试现有行为。修复测试。

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

绿 - 最少代码

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

<好>

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
}

过度工程 </坏>

不要添加功能、重构其他代码或在测试之外“改进”。

验证绿 - 观察通过

强制。

npm test 路径/到/测试.test.ts

确认：

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

测试失败？ 修复代码，而非测试。

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

重构 - 清理

仅在绿色之后：

  • 移除重复
  • 改进名称
  • 提取帮助函数

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

重复

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

好测试

质量 好 坏
最小 一件事。名称中有“和”？拆分它。 test('验证邮箱和域名和空白字符')
清晰 名称描述行为 test('test1')
展示意图 演示期望的API 模糊代码应该做什么

为何顺序重要

“我会在之后编写测试来验证它有效”

代码之后编写的测试立即通过。立即通过无法证明什么：

  • 可能测试错误的东西
  • 可能测试实现，而非行为
  • 可能忘记边缘情况
  • 你从未看到它捕获错误

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

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

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

  • 无记录显示你测试了什么
  • 代码变更时无法重新运行
  • 压力下容易忘记案例
  • “我尝试时有效” ≠ 全面

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

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

沉没成本谬误。时间已逝。你现在的选择：

  • 删除并用TDD重写（再加X小时，高置信度）
  • 保留并之后添加测试（30分钟，低置信度，可能包含错误）

“浪费”是保留无法信任的代码。没有真实测试的工作代码是技术债务。

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

TDD是务实的：

  • 在提交前发现错误（比之后调试更快）
  • 防止回归（测试立即捕获破坏）
  • 记录行为（测试展示如何使用代码）
  • 启用重构（自由更改，测试捕获破坏）

“务实”捷径 = 生产环境调试 = 更慢。

“之后测试达到相同目标 – 是精神而非仪式”

否。之后测试回答“这是什么做的？”先行测试回答“这应该做什么？”

之后测试受你的实现偏见影响。你测试你构建的，而非所需的。你验证记住的边缘情况，而非发现的边缘情况。

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

30分钟之后测试 ≠ TDD。你获得覆盖率，但失去测试有效的证明。

常见合理化

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

红旗 – 停止并从头开始

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

所有这些意味着：删除代码。用TDD从头开始。

示例：错误修复

错误： 接受空邮箱

红

test('拒绝空邮箱', async () => {
  const result = await submitForm({ email: '' });
  expect(result.error).toBe('邮箱必需');
});

验证红

$ npm test
FAIL: 期望'邮箱必需', 得到未定义

绿

function submitForm(data: FormData) {
  if (!data.email?.trim()) {
    return { error: '邮箱必需' };
  }
  // ...
}

验证绿

$ npm test
PASS

重构 如果需要，提取验证用于多个字段。

验证清单

在工作完成前：

  • [ ] 每个新函数/方法都有测试
  • [ ] 在实现前观察每个测试失败
  • [ ] 每个测试因预期原因失败（功能缺失，而非拼写错误）
  • [ ] 编写最少代码使每个测试通过
  • [ ] 所有测试通过
  • [ ] 输出纯净（无错误、警告）
  • [ ] 测试使用真实代码（除非不可避免，否则不用模拟）
  • [ ] 覆盖边缘情况和错误

无法勾选所有框？你跳过了TDD。从头开始。

当卡住时

问题 解决方案
不知道如何测试 编写期望的API。先写断言。询问您的人类伙伴。
测试太复杂 设计太复杂。简化接口。
必须模拟所有东西 代码耦合度太高。使用依赖注入。
测试设置巨大 提取帮助函数。仍复杂？简化设计。

调试集成

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

永不修复错误而无测试。

测试反模式

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

  • 测试模拟行为而非真实行为
  • 向生产类添加测试专用方法
  • 不理解依赖项而模拟

最终规则

生产代码 → 测试存在且先失败
否则 → 非TDD

未经您的人类伙伴许可，无例外。