---
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="/zh-Hant/docs/github-copilot/official/10-practical-playbooks/code-review" />
  <Card title="上下文與定製" description="把測試規範寫進 repository instructions 或 prompt files。" href="/zh-Hant/docs/github-copilot/official/06-context-customization" />
</Cards>
