在 VS Code 中設定測試驅動開發 (TDD) 流程

測試驅動開發 (TDD) 是一種軟體開發方法,您必須在實作功能之前先撰寫測試。這能建立緊密的意見回饋迴圈,不僅能改善程式碼品質、儘早捕捉錯誤,還能確保程式碼符合您的需求。Visual Studio Code 的 AI 功能可以引導您完成撰寫測試、實作程式碼、執行測試以及優化程式碼的不同階段,進而增強您的 TDD 工作流程。

本指南說明如何透過自訂代理人 (custom agents)、交接 (handoffs) 與自訂指令 (custom instructions),在 VS Code 中設定 AI 輔助的測試驅動開發工作流程。

TDD 概覽

測試驅動開發的核心原則是在實作之前先撰寫測試。測試定義了您想要建構之功能所需的預期結果。透過先撰寫測試,您可以釐清需求並找出邊緣案例 (edge cases),以確保您的程式碼運作符合預期。

TDD 遵循一個稱為 紅燈-綠燈-重構 (red-green-refactor) 的三階段週期,並針對每個小功能增量進行重複。

這三個階段分別為:

  • 紅燈階段 (Red phase):針對您想要開發的功能撰寫一個會失敗的測試。

  • 綠燈階段 (Green phase):撰寫讓測試通過所需的最小化應用程式程式碼。重點在於讓功能運作,而非追求完美。

  • 重構階段 (Refactor phase):在維持所有測試通過的前提下,改善程式碼品質。清理重複程式碼、優化命名並增強結構。

實作概覽

您可以利用自訂代理人在 VS Code 中實作 AI 輔助的 TDD 工作流程。TDD 流程的每個階段(紅燈、綠燈、重構)都有特定目標,且需要不同的 AI 行為。您可以為每個階段建立一個自訂代理人,定義該階段的角色與準則。

透過自訂代理人交接功能,您可以在 AI 完成任務後,從一個階段轉換到下一個階段。這些自訂代理人以鏡像 TDD 工作流程的循環方式相互連結:

  • 紅燈階段 → 在撰寫失敗測試後,交接給 綠燈階段
  • 綠燈階段 → 執行測試以驗證實作,然後交接給 重構階段
  • 重構階段 → 執行測試以確保仍然通過,然後交接回 紅燈階段 以開始下一個週期

如果您已建立測試規範,可以使用 自訂指令 來設定測試內容,引導 AI 產出符合專案標準的測試。

下圖顯示自訂代理人如何協同合作以實作 TDD 工作流程,並透過交接功能確保階段間的平順轉換。

Diagram that shows the TDD implementation diagram for VS Code with testing instructions, and custom agents for the red, green, and refactor phases.

提示

您可以在開始循環前增加一個「規劃階段」來進一步增強 TDD 工作流程。您可以使用內建的規劃代理人或建立自訂規劃代理人,幫助釐清需求並找出需要透過測試涵蓋的邊緣案例。

步驟 1:設定測試準則

如果您已建立測試慣例與實務規範,請建立一個自訂指令檔案 (testing.instructions.md),協助 AI 產生符合您專案標準的測試。

為什麼這樣做有幫助:若沒有明確的測試慣例,AI 可能會產生不符合您專案風格、模式不一致,或遺漏重要測試情境的測試。

若要設定測試準則:

  1. 在命令面板 (Command Palette) 中執行 Chat: Create Instructions File 命令,在工作區中建立新的指令檔案。

    • 選擇 .github/instructions 以在工作區中建立該指令檔案。
    • 將指令檔案命名為 "testing"。
    注意

    透過使用 *.instructions.md 檔案而非 copilot.instructions.md 檔案,您可以選擇性地僅將這些測試準則套用於專案中的測試檔案,而不會將其包含在所有的 AI 互動中。

  2. 更新指令的 applyTo 中繼資料,以便自動將其套用到測試檔案。同時設定 description 中繼資料,說明這些指令提供了測試內容。

    下列範例更新了 applyTo 欄位,以針對 tests/ 目錄中的所有檔案:

    ---
    description: 'Use these guidelines when generating or updating tests.'
    applyTo: tests/**
    ---
    
  3. 將您專案的測試準則加入指令檔案的內容中。

    下列範例提供了測試慣例的起點:

    ---
    description: 'Use these guidelines when generating or updating tests.'
    applyTo: tests/**
    ---
    # [Project Name] Testing Guidelines
    
    ## Test conventions
    * Write clear, focused tests that verify one behavior at a time
    * Use descriptive test names that explain what is being tested and the expected outcome
    * Follow Arrange-Act-Assert (AAA) pattern: set up test data, execute the code under test, verify results
    * Keep tests independent - each test should run in isolation without depending on other tests
    * Start with the simplest test case, then add edge cases and error conditions
    * Tests should fail for the right reason - verify they catch the bugs they're meant to catch
    * Mock external dependencies to keep tests fast and reliable
    
    提示

    您可以建立一個選用的測試結構範本,定義不同測試類型的區段與模式(例如 test-template.md)。在指令檔案中參照此範本,以便 AI 在產生測試時使用它。

步驟 2:建立「紅燈階段」自訂代理人

建立一個專注於 TDD 紅燈階段的 "TDD-red" 自訂代理人。此自訂代理人僅負責根據提供的需求撰寫失敗的測試,不應實作任何應用程式程式碼。完成後,此代理人會交接給綠燈階段的自訂代理人。

為什麼這樣做有幫助:若沒有這種專注模式,AI 可能會將實作建議與測試建立混雜在一起,導致忽略「先寫測試」這一 TDD 核心原則。

若要建立 .github/agents/TDD-red.agent.md 紅燈階段 自訂代理人

  1. 在命令面板中執行 Chat: New Custom Agent 命令。

    • 選擇 .github/agents 以在工作區中建立自訂代理人定義。
    • 將自訂代理人命名為 "TDD-red"。
  2. 更新自訂代理人定義,描述紅燈階段的準則與規則,並指定交接給綠燈階段的自訂代理人。

    下列 TDD-red.agent.md 檔案為紅燈階段提供了起點。

    ---
    name: TDD Red
    description: TDD phase for writing FAILING tests
    infer: true
    tools: ['read', 'edit', 'search']
    handoffs:
      - label: TDD Green
        agent: TDD Green
        prompt: Implement minimal implementation
    ---
    You are a test-writer: when given a function name, spec, or requirements, output a complete test file (or test function) that asserts the expected behavior, which must fail when run against the current codebase. Use the project’s style/conventions. Do not write implementation, only tests.
    

步驟 3:建立「綠燈階段」自訂代理人

建立一個專注於 TDD 綠燈階段的 "TDD-green" 自訂代理人。此自訂代理人僅負責撰寫讓測試通過的最小化實作程式碼,且不修改測試程式碼。實作完成後,此代理人會執行測試以驗證其通過,然後交接給重構階段的自訂代理人。

若要建立 .github/agents/TDD-green.agent.md 綠燈階段 自訂代理人

  1. 在命令面板中執行 Chat: New Custom Agent 命令。

    • 選擇 .github/agents 以在工作區中建立自訂代理人定義。
    • 將自訂代理人命名為 "TDD-green"。
  2. 更新自訂代理人定義,描述綠燈階段的準則與規則,並指定交接給重構階段的自訂代理人。

    下列 TDD-green.agent.md 檔案為綠燈階段提供了起點。

    ---
    name: TDD Green
    description: TDD phase for writing MINIMAL implementation to pass tests
    infer: true
    tools: ['search', 'edit', 'execute']
    handoffs:
      - label: TDD Refactor
        agent: TDD Refactor
        prompt: Refactor the implementation
    ---
    
    You are a code-implementer. Given a failing test case and context (existing codebase or module), write the minimal code change needed so that the test passes - no extra features. Do not write tests, only implementation.
    
    After implementing changes, run the tests to verify they pass.
    

步驟 4:建立「重構階段」自訂代理人

建立一個專注於 TDD 重構階段的 "TDD-refactor" 自訂代理人,旨在維持測試通過的前提下改善程式碼品質。此代理人負責清理程式碼、移除重複項、優化命名並增強結構,且不改變功能。重構完成後,此代理人會執行測試以確保仍然通過,然後交接回紅燈階段以開始下一個 TDD 週期。

若要建立 .github/agents/TDD-refactor.agent.md 重構階段 自訂聊天代理人

  1. 在命令面板中執行 Chat: New Custom Agent 命令。

    • 選擇 .github/agents 以在工作區中建立自訂代理人定義。
    • 將自訂代理人命名為 "TDD-refactor"。
  2. 更新自訂代理人定義,描述重構階段的準則與規則。

    下列 TDD-refactor.agent.md 檔案為重構階段提供了起點。

    ---
    name: TDD Refactor
    description: Refactor code while maintaining passing tests
    tools: ['search', 'edit', 'read', 'execute']
    infer: true
    handoffs:
      - label: TDD Red
        agent: TDD Red
        prompt: Start next TDD cycle with new test
    ---
    You are refactor-assistant. Given code that passes all tests, examine it and suggest or apply refactoring to improve readability/structure/DRYness, without changing behavior. No new functionality, no breaking changes.
    
    After refactoring, run the tests to ensure all tests still pass and behavior is preserved.
    

使用 TDD 工作流程來實作功能

現在 TDD 自訂代理人已設定完畢,您可以使用它們在專案中運用 TDD 工作流程來實作功能。

  1. 開啟聊天視圖 (Chat view),並從代理人下拉式選單中選擇 TDD Red 代理人。

  2. 提供一段提示詞 (prompt),描述您想要測試的功能或行為。

    例如

    Write tests for user registration with email validation and password requirements.
    
  3. 審查產生的測試,並使用交接動作來進行 TDD 週期的轉換。

    • 在測試撰寫完成後,選擇 TDD Green 以實作讓測試通過的最小化程式碼。
    • 綠燈代理人在實作後會自動執行測試。
    • 在測試通過後,選擇 TDD Refactor 以改善程式碼品質。
    • 重構代理人在重構後會自動執行測試,以確保它們仍然通過。
    • 選擇 TDD Red 以開始下一個包含額外功能的循環。

疑難排解與最佳實務

AI 進行 TDD 時的常見陷阱

未透過交接執行 TDD:使用單一代理人完成整個 TDD 週期會排除開發者的參與。交接提供了控制點,讓您可以在進入下一個階段前評估每個步驟、驗證 AI 的工作,並指引代理人朝正確的方向發展。

缺少功能測試涵蓋率:TDD 代理人專注於讓現有測試通過,不會實作沒有對應測試的功能。在期望實作包含該功能前,請確保規格中的每項需求都有測試涵蓋。

跳過紅燈階段:AI 可能會在撰寫測試之前就建議實作程式碼。

過度實作:AI 可能會產生比通過當前測試所需的程式碼更多的內容。請嚴格審查實作內容,並移除不必要的複雜性。

測試實作細節:測試應驗證行為,而非實作細節。如果重構需要更改測試,代表它們可能與實作細節耦合過緊。

測試涵蓋率不完整:AI 可能會遺漏邊緣案例或錯誤狀況。請嚴格審查產生的測試,並要求針對邊界條件、錯誤場景與邊緣案例進行額外的測試。

AI 輔助 TDD 的最佳實務

為任務選擇合適的模型:不同的語言模型各有優勢。考慮針對複雜的測試產生與邊緣案例識別使用推理模型。在聊天視圖中使用模型選擇器 (model picker) 在 TDD 工作流程期間切換模型,或在您的自訂代理人屬性中定義 model

驗證測試品質:在 AI 產生測試後,請審查它以確保它是因正確的原因而失敗。在實作前執行測試,驗證它是否能捕捉到遺漏的功能。

保持增量進度:透過 TDD 週期採取小步驟。寫一個測試、實作最小化程式碼、重構,然後重複。小規模的迭代可以防止大型錯誤,並保持程式碼庫的可運作狀態。

頻繁執行測試:在變更後立即執行測試。不要在累積多次變更後才測試。頻繁的測試執行能提供快速反饋並儘早發現問題。

將測試涵蓋率作為指南:高涵蓋率不保證品質,但低涵蓋率代表未測試的行為。請要求 AI 針對未涵蓋的程式碼路徑提出測試建議。

維持測試獨立性:測試應能以任何順序執行且互不影響。如果測試依賴執行順序或共用狀態,請進行重構以確保它們的獨立性。

根據需求更新測試內容:隨著專案發展,請更新指令檔案中的測試準則,以反映新的慣例、架構或實務規範。

深入了解 VS Code 中的測試與 AI 自訂設定

© . This site is unofficial and not affiliated with Microsoft.