test-driven-development

Test-Driven Development

概览

先写一个失败测试，再写让它通过的代码。修 bug 时，在尝试修复前先用测试复现 bug。测试是证据，“看起来对”不算完成。拥有良好测试的代码库是 AI agent 的超能力；没有测试的代码库则是一种负债。

何时使用

• 实现任何新逻辑或行为
• 修复任何 bug（Prove-It Pattern）
• 修改现有功能
• 添加边界情况处理
• 任何可能破坏现有行为的变更

何时不要使用： 纯配置变更、文档更新，或没有行为影响的静态内容变更。

相关： 对基于浏览器的变更，将 TDD 与使用 Chrome DevTools MCP 的运行时验证结合使用。见下方 Browser Testing 部分。

先发现技术栈

TDD 循环是通用的；命令不是。在写第一个测试之前，先弄清楚这个仓库是怎么测试的，并在每个 RED、GREEN 和验证步骤使用它自己的命令：

• 语言与构建系统 —— package.json、pom.xml/build.gradle、pyproject.toml、go.mod、Cargo.toml、Gemfile、Makefile
• 仓库内置的 wrapper —— 优先用 ./gradlew、./mvnw、make test 或仓库脚本，而不是全局安装的工具
• 测试框架与配置 —— 以及它如何运行单个聚焦测试 vs 完整套件
• 现有约定 —— 测试放在哪里、文件怎么命名、相邻测试遵循什么模式
• 已记录的命令 —— README、CONTRIBUTING 和 CI workflows 展示的是真正把关合并的命令

在循环中运行仓库的聚焦测试命令，在完成前运行它的完整套件命令。绝不要假设 npm test 这类默认值；Gradle、Cargo 或 pytest 项目都有各自的等价命令。

下面的示例用 TypeScript 演示；一旦你发现了项目自己的工具链，这个工作流在任何语言里都完全相同。

TDD 循环

    RED                GREEN              REFACTOR
 Write a test    Write minimal code    Clean up the
 that fails  ──→  to make it pass  ──→  implementation  ──→  (repeat)
      │                  │                    │
      ▼                  ▼                    ▼
   Test FAILS        Test PASSES         Tests still PASS

步骤 1：RED，编写失败测试

先写测试。它必须失败。一个立即通过的测试什么都证明不了。

// RED: This test fails because createTask doesn't exist yet
describe('TaskService', () => {
  it('creates a task with title and default status', async () => {
    const task = await taskService.createTask({ title: 'Buy groceries' });

    expect(task.id).toBeDefined();
    expect(task.title).toBe('Buy groceries');
    expect(task.status).toBe('pending');
    expect(task.createdAt).toBeInstanceOf(Date);
  });
});

步骤 2：GREEN，让它通过

编写最少代码让测试通过。不要过度工程化：

// GREEN: Minimal implementation
export async function createTask(input: { title: string }): Promise<Task> {
  const task = {
    id: generateId(),
    title: input.title,
    status: 'pending' as const,
    createdAt: new Date(),
  };
  await db.tasks.insert(task);
  return task;
}