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

測試驅動開發 (TDD) 是一種軟體開發方法,您在實作功能之前撰寫測試。這建立了一個緊密的意見回饋迴圈,可以改善程式碼品質、提早發現錯誤,並確保程式碼符合您的需求。Visual Studio Code 的 AI 功能可以引導您完成撰寫測試、實作程式碼、執行測試及最佳化程式碼的不同階段,藉此提升您的 TDD 工作流程。

本指南將說明如何在 VS Code 中,藉由使用自訂代理程式、交接和自訂指示,設定一個由 AI 輔助的測試驅動開發工作流程。

TDD 概觀

測試驅動開發的核心原則是在實作之前撰寫測試。這些測試定義了您想要建置之功能的預期結果。藉由先撰寫測試,您可以釐清需求並識別邊際案例,以確保程式碼的行為符合預期。

TDD 遵循一個三階段的循環,稱為 紅-綠-重構,並針對每個小功能增量重複進行。

這三個階段是

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

  • 綠燈階段:撰寫最少的應用程式碼,以使測試通過。專注於使其運作,而非使其完美。

  • 重構階段:改善程式碼品質,同時保持所有測試都通過。清理重複程式碼、改善命名並強化結構。

實作概觀

您可以藉由使用自訂代理程式,在 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. 在命令選擇區中執行 Chat: 建立指示檔案 命令,以在您的工作區中建立新的指示檔案。

    • 選取 .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-red」自訂代理程式,專注於 TDD 的紅燈階段。此自訂代理程式僅負責根據提供的需求撰寫失敗的測試,不應實作任何應用程式碼。完成後,此代理程式會交接給綠燈階段自訂代理程式。

為何這有幫助:如果沒有專注模式,AI 可能會將實作建議與測試建立混淆,並錯過先撰寫測試的核心 TDD 原則。

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

  1. 在命令選擇區中執行 Chat: 新增自訂代理程式 命令。

    • 選取 .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-green」自訂代理程式,專注於 TDD 的綠燈階段。此自訂代理程式僅負責撰寫最少的實作程式碼以使測試通過,而不修改測試程式碼。實作後,此代理程式會執行測試以驗證它們是否通過,然後交接給重構階段自訂代理程式。

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

  1. 在命令選擇區中執行 Chat: 新增自訂代理程式 命令。

    • 選取 .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-refactor」自訂代理程式,專注於 TDD 的重構階段,以改善程式碼品質,同時保持所有測試都通過。此代理程式負責清理程式碼、移除重複程式碼、改善命名,並強化結構而不改變功能。重構後,此代理程式會執行測試以確保它們仍然通過,然後交接回紅燈階段以開始下一個 TDD 循環。

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

  1. 在命令選擇區中執行 Chat: 新增自訂代理程式 命令。

    • 選取 .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. 開啟「聊天」檢視,並從代理程式下拉式功能表中選取 TDD 紅燈 代理程式。

  2. 提供一個描述您想要測試的功能或行為的提示。

    例如

    Write tests for user registration with email validation and password requirements.
    
  3. 檢閱生成的測試,並使用交接動作在 TDD 循環中轉換

    • 撰寫測試後,選取 TDD 綠燈 以實作最少的程式碼,使測試通過。
    • 綠燈代理程式在實作後會自動執行測試。
    • 測試通過後,選取 TDD 重構 以改善程式碼品質。
    • 重構代理程式在重構後會自動執行測試,以確保它們仍然通過。
    • 選取 TDD 紅燈 以開始具有額外功能的下一個循環。

疑難排解與最佳實務

與 AI 相關的常見 TDD 陷阱

未經交接執行 TDD:使用單一代理程式完成整個 TDD 循環會將人類從循環中移除。交接提供了控制點,您可以在其中評估每個步驟、驗證 AI 的工作,並在進入下一個階段之前,引導代理程式朝正確的方向前進。

功能缺少測試涵蓋範圍:TDD 代理程式專注於使現有測試通過,並且不會實作沒有相應測試的功能。在預期實作會包含它之前,請確保您的規範中的每個需求都具有測試涵蓋範圍。

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

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

測試實作細節:測試應該驗證行為,而不是實作。如果重構需要變更測試,它們可能與實作細節過於緊密耦合。

不完整的測試涵蓋範圍:AI 可能會錯過邊際案例或錯誤條件。嚴格審查生成的測試,並要求涵蓋邊界條件、錯誤情境和邊際案例的額外測試。

適用於 AI 的 TDD 最佳實務

為任務選擇正確的模型:不同的語言模型有不同的優勢。考慮使用推理模型來生成複雜測試和識別邊際案例。使用「聊天」檢視中的模型選取器在您的 TDD 工作流程中切換模型,或在您的自訂代理程式屬性中定義 model

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

維持漸進式進度:在 TDD 循環中採取小步驟。撰寫一個測試、實作最少的程式碼、重構,然後重複。小迭代可防止重大錯誤並保持程式碼庫正常運作。

頻繁執行測試:變更後立即執行測試。在測試之前不要累積多個變更。頻繁的測試執行提供快速意見回饋並提早發現問題。

使用測試涵蓋範圍作為指南:高涵蓋範圍不保證品質,但低涵蓋範圍表示未測試的行為。要求 AI 為未涵蓋的程式碼路徑建議測試。

維持測試獨立性:測試應該以任何順序執行而不互相影響。如果測試依賴於執行順序或共用狀態,請進行重構以使其獨立。

視需要更新測試內容:隨著您的專案演進,請更新指示檔案中的測試準則,以反映新的慣例、框架或實務。

進一步瞭解 VS Code 中的測試與 AI 自訂

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