TDD 工作流
用 Copilot 辅助 Red / Green / Refactor：先写失败测试，再做最小实现，最后重构并保持测试通过。
TDD（test-driven development，测试驱动开发）工作流的重点不是“让 Copilot 多写代码”，而是把 Copilot 限制在小步循环里。先让测试失败（Red），再让实现刚好通过（Green），最后只重构结构不改行为（Refactor）——三步缺一道，TDD 就退化成"AI 代写代码 + 事后补测试"。
VS Code 官方 TDD 指南把 AI 辅助 TDD 拆成 Red、Green、Refactor 三个阶段，并建议用自定义 agent、handoff 和自定义指令保持阶段边界。
1. 先给结论
Copilot 适合参与 TDD，但不能跳过 Red phase。最稳的做法是让它一次只完成一个阶段，并在阶段切换前由开发者检查测试、diff 和运行结果。
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:2px2. 输入要准备什么
开始前把上下文压到可验证：
- 一条明确行为，而不是一整个模块。
- 现有测试框架和测试命令。
- 相关源码入口、接口约束和边界条件。
- 项目测试风格，例如命名、fixture、mock、断言偏好。
- 不允许改变的行为，例如兼容性、性能、权限和数据格式。
可以先在仓库里写一段团队级测试指令，例如放在 repository instructions 或测试规范里，告诉 Copilot 测试命名、mock 边界和禁止行为。
3. Red phase：只写失败测试
在 Chat 或 agent 模式里明确要求 Copilot 只写测试，不写实现：
写一个最小失败测试。
不要修改生产代码。
行为：
- 重复 email 返回 409。
- 响应体包含 code=EMAIL_EXISTS。
约束：
- 使用现有测试框架和 fixture。
- 只覆盖这个行为。
- 告诉我测试命令。人工检查点：
- 测试是否验证行为，而不是锁死实现细节。
- 测试是否先失败，并且失败原因正是目标行为缺失。
- 是否没有顺手改生产代码。
- 边界条件是否足够，是否需要补错误路径或权限路径。
如果测试没有失败，说明它没有建立约束；如果失败原因不对，先修测试，不进入 Green phase。
4. Green phase：只做最小实现
进入 Green phase 时，把失败测试和错误输出给 Copilot：
只修改实现。
让刚才这个失败测试通过。
要求：
- 不扩大功能范围。
- 不重写无关模块。
- 不新增抽象。
- 完成后运行相关测试。
- 说明改动点。人工检查点：
- 实现是否只覆盖当前测试约束。
- 是否引入了多余配置、全局状态或异常分支。
- 是否破坏了相邻测试。
- 是否能用一次 diff 解释清楚。
Copilot 很容易在 Green phase 过度实现。看到“顺手支持更多场景”的改动，先删掉或要求它缩小范围。
5. Refactor phase：只清理结构
Refactor phase 的输入是“测试已通过的代码”。这一步不新增行为：
在测试通过的前提下，
检查这次实现是否需要重构。
只允许：
- 消除重复。
- 改善命名。
- 缩小函数职责。
- 移除临时变量或过度分支。
不允许：
- 新增功能。
- 改测试预期。
- 改外部 API。这一步的退出条件是相关测试仍然通过，且 diff 比实现阶段更清晰。如果重构让测试需要一起改，先判断测试是否绑死实现；不能默认接受。
6. 常见失败点
- 跳过 Red phase：Copilot 直接写实现，再补测试，TDD 约束消失。
- 一次做太大：一个 prompt 覆盖多个行为，失败时无法定位原因。
- 测试实现细节：重构时测试跟着碎，说明断言对象选错。
- 只看绿色结果：测试通过不代表覆盖了错误路径、边界值和权限路径。
- 无人工 handoff：一个 agent 连续写测试、实现、重构，开发者只看最后结果。
深读：什么时候不适合 TDD + Copilot
需求还没有行为边界、现有代码没有测试框架、接口仍在剧烈变化时，不要急着让 Copilot 写一堆测试。先把行为样例、接口契约和测试命令定下来。
Copilot 可以帮你补测试，但不能替你决定产品行为。
本章自检
- 是否每次只写一个行为的失败测试？
- 是否确认测试先因正确原因失败？
- 是否只做让当前测试通过的最小实现？
- 是否在重构后重新运行相关测试？
- 是否把成功 prompt 和失败样例沉淀进团队 SOP？
通过标准：你能展示 Red 失败输出、Green 通过输出、Refactor 后通过输出，以及每一步的 diff。
官方来源
- Set up a test-driven development flow in VS Code —— VS Code 官方 TDD 指南。
- GitHub Copilot in VS Code —— VS Code 官方 Copilot 总览。