---
title: "TDD 工作流"
description: "用 Copilot 辅助 Red / Green / Refactor：先写失败测试，再做最小实现，最后重构并保持测试通过。"
verifiedAt: "2026-05-06"
---

TDD（test-driven development，测试驱动开发）工作流的重点不是“让 Copilot 多写代码”，而是把 Copilot 限制在小步循环里。先让测试失败（Red），再让实现刚好通过（Green），最后只重构结构不改行为（Refactor）——三步缺一道，TDD 就退化成"AI 代写代码 + 事后补测试"。

> [!NOTE]
> VS Code 官方 TDD 指南把 AI 辅助 TDD 拆成 Red、Green、Refactor 三个阶段，并建议用自定义 agent、handoff 和自定义指令保持阶段边界。

## 1. 先给结论

Copilot 适合参与 TDD，但不能跳过 Red phase。最稳的做法是让它一次只完成一个阶段，并在阶段切换前由开发者检查测试、diff 和运行结果。

```mermaid
flowchart LR
    Spec["需求 / 行为描述"] --> Red["Red: 写失败测试"]
    Red --> CheckRed{"测试是否因目标行为失败?"}
    CheckRed -->|否| Red
    CheckRed -->|是| Green["Green: 最小实现"]
    Green --> CheckGreen{"测试是否通过?"}
    CheckGreen -->|否| Green
    CheckGreen -->|是| Refactor["Refactor: 清理结构"]
    Refactor --> CheckRefactor{"全量相关测试仍通过?"}
    CheckRefactor -->|否| Refactor
    CheckRefactor -->|是| Next["下一条行为"]

    style Red fill:#fee2e2,stroke:#dc2626,stroke-width:2px
    style Green fill:#dcfce7,stroke:#16a34a,stroke-width:2px
    style Refactor fill:#dbeafe,stroke:#2563eb,stroke-width:2px
```

## 2. 输入要准备什么

开始前把上下文压到可验证：

- 一条明确行为，而不是一整个模块。
- 现有测试框架和测试命令。
- 相关源码入口、接口约束和边界条件。
- 项目测试风格，例如命名、fixture、mock、断言偏好。
- 不允许改变的行为，例如兼容性、性能、权限和数据格式。

可以先在仓库里写一段团队级测试指令，例如放在 repository instructions 或测试规范里，告诉 Copilot 测试命名、mock 边界和禁止行为。

## 3. Red phase：只写失败测试

在 Chat 或 agent 模式里明确要求 Copilot 只写测试，不写实现：

```txt
写一个最小失败测试。
不要修改生产代码。

行为：
- 重复 email 返回 409。
- 响应体包含 code=EMAIL_EXISTS。

约束：
- 使用现有测试框架和 fixture。
- 只覆盖这个行为。
- 告诉我测试命令。
```

人工检查点：

1. 测试是否验证行为，而不是锁死实现细节。
2. 测试是否先失败，并且失败原因正是目标行为缺失。
3. 是否没有顺手改生产代码。
4. 边界条件是否足够，是否需要补错误路径或权限路径。

如果测试没有失败，说明它没有建立约束；如果失败原因不对，先修测试，不进入 Green phase。

## 4. Green phase：只做最小实现

进入 Green phase 时，把失败测试和错误输出给 Copilot：

```txt
只修改实现。
让刚才这个失败测试通过。

要求：
- 不扩大功能范围。
- 不重写无关模块。
- 不新增抽象。
- 完成后运行相关测试。
- 说明改动点。
```

人工检查点：

- 实现是否只覆盖当前测试约束。
- 是否引入了多余配置、全局状态或异常分支。
- 是否破坏了相邻测试。
- 是否能用一次 diff 解释清楚。

Copilot 很容易在 Green phase 过度实现。看到“顺手支持更多场景”的改动，先删掉或要求它缩小范围。

## 5. Refactor phase：只清理结构

Refactor phase 的输入是“测试已通过的代码”。这一步不新增行为：

```txt
在测试通过的前提下，
检查这次实现是否需要重构。

只允许：
- 消除重复。
- 改善命名。
- 缩小函数职责。
- 移除临时变量或过度分支。

不允许：
- 新增功能。
- 改测试预期。
- 改外部 API。
```

这一步的退出条件是相关测试仍然通过，且 diff 比实现阶段更清晰。如果重构让测试需要一起改，先判断测试是否绑死实现；不能默认接受。

## 6. 常见失败点

- **跳过 Red phase**：Copilot 直接写实现，再补测试，TDD 约束消失。
- **一次做太大**：一个 prompt 覆盖多个行为，失败时无法定位原因。
- **测试实现细节**：重构时测试跟着碎，说明断言对象选错。
- **只看绿色结果**：测试通过不代表覆盖了错误路径、边界值和权限路径。
- **无人工 handoff**：一个 agent 连续写测试、实现、重构，开发者只看最后结果。

<details>
<summary>深读：什么时候不适合 TDD + Copilot</summary>

需求还没有行为边界、现有代码没有测试框架、接口仍在剧烈变化时，不要急着让 Copilot 写一堆测试。先把行为样例、接口契约和测试命令定下来。

Copilot 可以帮你补测试，但不能替你决定产品行为。
</details>

## 本章自检

1. 是否每次只写一个行为的失败测试？
2. 是否确认测试先因正确原因失败？
3. 是否只做让当前测试通过的最小实现？
4. 是否在重构后重新运行相关测试？
5. 是否把成功 prompt 和失败样例沉淀进团队 SOP？

通过标准：你能展示 Red 失败输出、Green 通过输出、Refactor 后通过输出，以及每一步的 diff。

## 官方来源

- [Set up a test-driven development flow in VS Code](https://code.visualstudio.com/docs/copilot/guides/test-driven-development-guide) —— VS Code 官方 TDD 指南。
- [GitHub Copilot in VS Code](https://code.visualstudio.com/docs/copilot/overview) —— VS Code 官方 Copilot 总览。

## 接下来去哪

<Cards>
  <Card title="代码审查工作流" description="TDD 之后，用 Copilot review 帮你预筛风险。" href="/docs/github-copilot/official/10-practical-playbooks/code-review" />
  <Card title="上下文与定制" description="把测试规范写进 repository instructions 或 prompt files。" href="/docs/github-copilot/official/06-context-customization" />
</Cards>
