测试驱动开发

技能文档

---
name: tdd
description: 测试驱动开发（TDD）技能。当用户要求先写测试再实现功能、测试驱动开发、red-green-refactor、写集成测试、测试先行时触发。
title: 测试驱动开发
category: 开发工具
---

# 测试驱动开发（TDD）

TDD 是 red → green 循环。本技能让该循环产出值得保留的测试：什么是好测试、测试写在哪、有哪些反模式、循环遵守什么规则。每个环节在每个循环中都适用——在循环开始前和进行中查阅，而不是事后补救。

探索代码库时，若存在 `CONTEXT.md` 请先阅读，使测试命名与项目领域语言一致，并遵守所触碰模块的 ADR 约定。

## 技能工作流

调用 `todo_write` 工具创建待办任务：

确认 seams → 写失败测试（red）→ 最小实现（green）→ 垂直切片迭代 → 移交 review

### 步骤1：确认 seams（测试边界）

**seam** 是测试的公共边界：在不深入内部的前提下观察行为的接口。测试只写在 seam 上，绝不对着内部实现写。

**只在预先确认的 seam 上测试。** 写任何测试之前，先列出被测 seam 并与用户确认。未确认的 seam 不写测试。测试无法覆盖一切——事先约定 seam 才能让测试投入落在关键路径和复杂逻辑上，而不是每个边界条件。

向用户确认："公共接口是什么？我们应该测哪些 seam？"

**异常处理**：
- 用户无法确认 seam → 暂停写测试，先基于代码库分析给出 seam 建议清单供选择
- 待测模块无公共接口（纯内部逻辑）→ 建议先重构出 seam，而非测试私有方法

### 步骤2：写失败测试（red）

针对一个 seam 写一个失败测试：

- 测试名描述行为而非实现，如 "user can checkout with valid cart"
- 期望值来自独立的真值来源——已知常量、演算示例、规格说明，禁止按实现逻辑重算
- 只通过公共接口验证，禁止查库等旁路验证
- 好/坏测试示例见 [references/tests.md](references/tests.md)

运行测试，确认它确实失败且失败原因正确。

### 步骤3：最小实现（green）

只写刚好能让测试通过的代码：

- 不为未来的测试做预设，不加投机性功能
- mock 仅限系统边界（外部 API、时间/随机数等），不 mock 自己可控的代码，详见 [references/mocking.md](references/mocking.md)

运行测试确认通过。

### 步骤4：垂直切片迭代

按「一个测试 → 一份实现」的节奏重复步骤2-3：

- 禁止水平切片——不要先写完所有测试再统一实现，批量测试只会验证想象中的行为
- 每个测试都是**曳光弹**（tracer bullet），根据上一轮循环学到的东西调整下一轮
- 一个循环只动一个 seam、一个测试、一份最小实现

### 步骤5：移交 review

循环内不做重构。重构属于 review 阶段，全部测试通过后再统一进行；评审与重构可借助代码评审类技能完成。

## 反模式速查

| 反模式 | 特征 | 识别信号 |
|--------|------|----------|
| 实现耦合 | mock 内部协作者、测私有方法、旁路验证（绕过接口查库） | 重构后行为没变但测试挂了 |
| 同义反复 | 期望值按代码的算法重算（如 `expect(add(a, b)).toBe(a + b)`） | 测试天生就会通过，永远无法与代码产生分歧 |
| 水平切片 | 先写完所有测试再统一实现 | 测试验证的是想象中的行为，对真实变更不敏感 |

## 循环规则

- **Red 先于 green。** 先写失败测试，再写刚好让它通过的代码。
- **一次只切一片。** 一个循环 = 一个 seam + 一个测试 + 一份最小实现。
- **重构不在循环内。** 重构属于 review 阶段，不属于 red → green 实现循环。

## 使用说明

| 场景 | 触发示例 |
|------|----------|
| 测试先行开发功能 | 「用 TDD 实现购物车结算」「先写测试再写实现」 |
| 测试先行修 bug | 「先写复现测试再修这个 bug」 |
| 集成测试 | 「给这个模块补集成测试」 |

执行时从「步骤1：确认 seams」开始，与用户确认后再进入循环。

使用说明

# 测试驱动开发（TDD）

按 red → green 循环进行测试驱动开发的技能：先写失败测试，再写最小实现，垂直切片迭代。

## 触发方式

- 「用 TDD 实现 xxx」「先写测试再写实现」
- 「先写复现测试再修这个 bug」
- 「给这个模块补集成测试」「red-green-refactor」

## 核心流程

1. **确认 seams**：与用户确认测试的公共边界，未确认不写测试
2. **Red**：写一个描述行为的失败测试
3. **Green**：只写刚好让测试通过的最小实现
4. **迭代**：一个测试 → 一份实现，垂直切片推进
5. **移交 review**：循环内不重构，测试全绿后统一重构

## 核心原则

- 测试通过公共接口验证行为，不测实现细节
- 期望值来自独立真值（已知常量/规格），禁止按实现逻辑重算
- mock 仅限系统边界（外部 API、时间等），不 mock 自己可控的代码

## 目录说明

- `SKILL.md`：工作流与循环规则
- `references/tests.md`：好测试/坏测试示例
- `references/mocking.md`：mock 边界与可 mock 性设计

如何安装此技能？

访问技能市场，点击「安装」按钮，按提示将技能包放入 AI 编程助手的 skills 目录即可。