先写测试。看着它失败。编写最少的代码来通过。

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

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

例外情况（询问你的合作伙伴）：

想着"就这一次跳过 TDD"？停下来。那是合理化。

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

在测试之前写了代码？删掉它。重新开始。

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

编写一个显示预期结果的最小测试。

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

清晰的名称，测试真实行为，只测一件事

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

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

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

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

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

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

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

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

保持测试通过。不要添加行为。

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

最小化 只测一件事。名称里有"和"？拆开。 test('validates email and domain and whitespace')

显示意图 展示期望的 API 掩盖代码应该做什么

"我先写测试然后再验证它能工作"

事后编写的测试会立即通过。立即通过证明不了什么：

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

"我已经手动测试了所有边界情况"

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

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

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

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

"TDD 是教条的，务实意味着适应"

"务实"的捷径 = 在生产环境调试 = 更慢。

"事后测试达到相同目标 - 这是精神而非仪式"

不。事后测试回答"这段代码做什么？"测试优先回答"这段代码应该做什么？"

事后测试受到你的实现偏见的影响。你测试你构建的东西，而不是需要的东西。你验证你记得的边界情况，而不是发现的那些。

测试优先迫使你在实现之前发现边界情况。事后测试验证你记得所有东西（你没有）。

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

"太简单不需要测试" 简单的代码也会坏。测试只需 30 秒。

"我之后会测试" 立即通过的测试证明不了什么。

"事后测试达到相同目标" 事后测试 = "这做什么？" 测试优先 = "这该做什么？"

"已经手动测试过了" 临时的 ≠ 系统化的。没有记录，无法重新运行。

"删除 X 小时是浪费" 沉没成本谬误。保留未验证的代码是技术债务。

测试驱动开发（TDD）实践指南

TDD 红-绿-重构循环的完整实践指引，覆盖单元测试设计、重构节奏与常见陷阱。

编程语言

测试

开发工具

测试驱动开发（TDD）完整实践指南：掌握红-绿-重构循环，先写失败测试再写最小代码。覆盖单元测试设计、常见陷阱规避与缺陷修复流程，附验证清单与反模式解析，助你快速上手高效开发。

单元测试

Agent

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

测试驱动开发（TDD）实践指南

测试驱动开发（TDD）实践指南

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐