test-driven-development

test-driven-development skill 概覽

test-driven-development skill 實際會做什麼

test-driven-development skill 會為 AI 代理套用一套嚴格的 TDD 工作流程，用於功能開發、錯誤修正與行為變更：先寫測試、確認它是因為正確的原因而失敗，再寫出剛好能通過的最少正式程式碼，最後再安全重構。它的核心價值不只是「順便把測試也寫一寫」，而是強制執行正確順序，讓實作真正由可執行的行為規格來驅動。

這個 skill 最適合哪些人

這個 test-driven-development skill 很適合把 AI 用在真實 repository 開發工作的開發者，尤其是正確性很重要的情境：例如應用功能、服務邏輯、bug 修復、重構與避免回歸。若你常遇到模型直接跳進實作、沒有先界定可驗證行為，這個 skill 特別有幫助，因為它會迫使流程拆成更小、可檢查的步驟。

它真正解決的工作需求

多數人會安裝 test-driven-development，是因為一般 coding prompt 往往先產生程式碼，再事後補測試。這個 skill 會改變那種行為。它讓實作建立在「先失敗的測試」之上，因此代理產出的內容更容易審查，也較不容易憑空補出未驗證的行為。

它和一般「幫我寫測試」prompt 的真正差異

差異關鍵在於這個 skill 的「鐵律」：沒有先失敗的測試，就不能寫正式程式碼。這比一般提示嚴格得多。它也特別強調，第一個失敗必須是「正確的失敗」，不能只是任何紅燈都算數；這是很實務的防呆機制，而許多流於表面的 TDD 說明常常忽略這一點。

安裝前要先知道的重要限制

這是一個流程型 skill，不是針對特定框架的測試工具包。它不會幫你決定完整的測試架構，也沒有附帶 helper scripts 或大量參考資料，除了 SKILL.md 和 testing-anti-patterns.md 之外支援內容不多。如果你需要的是深入的 Jest、Pytest、JUnit 或 Playwright 設定教學，這個 skill 更適合作為工作流程層，而不是完整的測試手冊。

如何使用 test-driven-development skill

安裝 test-driven-development skill

可用以下指令從 repository 安裝：

npx skills add https://github.com/obra/superpowers --skill test-driven-development

如果你的環境支援本機 skill discovery，請先確認這個 skill 會以 test-driven-development 出現，並且在開始做功能開發前已可供代理使用。

先讀這些檔案

對這個 test-driven-development install 與使用流程，建議先看：

• skills/test-driven-development/SKILL.md
• skills/test-driven-development/testing-anti-patterns.md

先讀 SKILL.md，掌握整體流程與限制。若你的任務涉及 mocks、隔離測試、UI 測試，或有衝動想在正式程式碼裡加入只為測試存在的接縫，接著一定要讀 testing-anti-patterns.md。

先準備好這個 skill 需要的最低輸入

這個 skill 在你提供以下資訊時效果最好：

• 要做的功能、bug 或行為變更
• 相關檔案或模組邊界
• repository 目前使用的測試框架
• 期望的使用者可見或系統可見行為
• API 形狀、向下相容性或效能上的限制

如果缺少這些上下文，代理仍然可以機械式地套用 TDD，但很可能會選錯測試層級，或寫出比較迎合工具、卻不貼合你程式碼庫的測試。

把模糊需求改寫成可做 TDD 的 prompt

較弱的 prompt：

Add support for password reset.

較強的 prompt：

Use the test-driven-development skill. We need password reset in the existing Node/Express app. Write the first failing integration or service-level test before any production code. Verify the failure is for missing reset behavior, not setup issues. Then implement the minimum code to pass. Keep the current route style, use Jest, and avoid changing unrelated auth flows.

較強的版本提供了足夠上下文，讓代理可以選對第一個測試，並遵守 red-green-refactor 循環。

把這個 skill 當成分步流程用，不要一次生成整包

一個實際可行的 test-driven-development usage 模式是：

1. 先只要求第一個失敗測試。
2. 檢查這個失敗是否真的對準預期行為。
3. 再要求能讓它通過的最小實作。
4. 只有在 green 之後才要求重構。
5. 對下一個小的行為切片重複同樣流程。

這樣通常會比一次要求完整功能產出更好，因為這個 skill 本來就是圍繞「小步、可驗證增量」而設計的。

正確驗證「red」階段

這份 test-driven-development guide 的一個關鍵細節是：測試失敗本身還不夠。這個失敗必須能證明測試真的對準了缺少的正確行為。如果測試是因為 import error、fixture 壞掉，或其他不相干的 setup 問題而失敗，那其實還不算真正開始這個循環。

在下 prompt 時，請明確要求代理說明：測試為什麼失敗，以及為什麼這個失敗是正確的失敗。

為 test-driven-development skill 選對第一個測試

最好的第一個測試，通常是最小但對外仍有意義的行為變更。好的候選包括：

• 重現一個 bug
• 一條商業規則
• 一個 endpoint 回應變更
• 一個 domain method 的行為
• 一個對使用者影響明確的 UI 互動

不好的起點則包括巨大的 end-to-end 情境、範圍很廣的 snapshot 覆蓋，或過早把內部實作綁死的測試。

一旦出現 mocks，就套用 anti-pattern 指南

如果代理開始過度使用 mocks，testing-anti-patterns.md 就很重要。這個 skill 明確警告，不要去測 mock 的行為，而要測真實行為。這點對 test-driven-development for Test Automation 特別重要，因為 AI 代理常會寫出針對 mock placeholder 的斷言，因為那比驗證真實輸出更容易滿足。

如果測試只是在檢查某個 mock 有 render、某個 mock 被很表面地呼叫，或為了讓測試成立而不得不在正式程式碼中加入只給測試用的方法，就該停下來重新界定測試範圍。

要求代理遵守這條鐵律

如果模型已經先草擬了實作，這個 skill 自身的指引是很嚴格的：刪掉正式程式碼，從失敗測試重新開始。實務上你不需要太戲劇化，但應該明確要求代理忽略先前猜測式的實作，重新依照 test-first 順序產生內容。

可直接使用這樣的措辭：

Do not continue from implementation-first code. Restart with a failing test and derive the implementation from that test.

讓這個 skill 對齊你 repository 的測試技術棧

這個 skill 以流程為核心，所以你需要把它綁定到自己的技術棧：

• Python services 用 pytest
• JS/TS 邏輯用 Jest 或 Vitest
• Ruby 用 RSpec
• Java 用 JUnit
• Playwright 或同類工具只在行為真的屬於瀏覽器層時再用

如果你的 repo 已經有清楚的 test pyramid，請直接告訴代理這次變更應落在哪一層。否則模型很可能會預設採用最顯眼的測試型態，而不是成本最低、但已足夠有效的那一種。

真實 repository 工作可用的 prompt 範例

一個扎實的 test-driven-development skill prompt 可以長這樣：

Use the test-driven-development skill for a bug fix. In billing/invoice_service.py, invoices with zero-amount adjustments should remain payable if tax is still due. Start by writing the smallest failing pytest that reproduces the current bug. Confirm the failure is caused by the missing business rule, not fixture issues. Then implement the minimum fix, run or describe the expected green result, and suggest any safe refactor only after the test passes.

這個 prompt 同時提供了行為、位置、框架與審查標準。

test-driven-development skill 常見問題

如果我本來就懂 TDD，還值得安裝 test-driven-development 嗎？

值得，如果你的主要問題是讓 AI 代理真的照著 TDD 做，而不是只會嘴上談 TDD。test-driven-development skill 的價值比較不在教學，而是在替模型加上行為約束。

這個 skill 對新手友善嗎？

大致上算友善。流程本身簡單而且明確。對初學者來說，較難的是選對第一個測試與正確測試層級。如果你剛接觸測試，建議先拿這個 skill 用在小型 bug 修正，而不是直接套用到大型新功能。

什麼情況下 test-driven-development 不太適合？

對一次性原型、生成式程式碼，或純設定檔修改來說，它通常不是最理想的選擇，除非正確性風險很高，而且人工審查者仍希望維持 test-first 紀律。來源指引也明確把這些情況視為需要和人類協作者討論的例外。

它和一般 prompt 有什麼不同？

一般 prompt 常寫成「實作 X 並加上測試」。這個 skill 改變的是工作順序，而且把這個順序視為不可妥協。真正的價值就在這個排序，因為它能減少幻想式實作，並提高可審查性。

這個 skill 也涵蓋框架設定嗎？

不算深入。test-driven-development install 本身很直接，但 skill 內容並沒有提供大量框架專屬的設定文件。它假設你能把代理導向現有的測試技術棧或 repository 慣例。

我可以把 test-driven-development 用在重構嗎？

可以。當你需要確保行為維持穩定時，它很適合拿來做重構。實務上的模式通常是先用測試把目前行為鎖住，再在 green 的保護下進行重構。

它適合 UI 與 end-to-end 測試嗎？

有時候適合，但要小心使用。做 UI 工作時，anti-pattern 檔案特別重要，因為 AI 很容易滑向驗證 mock 是否存在，或驗證實作痕跡，而不是驗證真實使用者行為。請從你能驗證的最小真實使用者行為開始。

如何改善 test-driven-development skill 的使用效果

提供行為，不要先給解法

想得到更好的 test-driven-development usage，請描述預期行為與限制，而不是直接指定實作方式。TDD 最有效的狀態，是讓測試先界定結果，再讓程式碼從那些檢查中自然長出來。

較好的輸入：
Users should see an error when uploading files over 10MB.

較差的輸入：
Add a fileSizeValidator class and call it from the controller.

前者會保留空間，讓代理找到更乾淨、更精簡的實作。

明確指定你要的測試層級

很多品質不佳的結果，其實都來自測試範圍選錯。直接告訴代理你要的是：

• 單元層級的商業邏輯
• 圍繞 service 或 API 的整合測試
• 瀏覽器層級的行為

這一個選擇的重要性，往往比其他多數 prompt 細節都高。

強迫切成更小的增量

常見失敗模式之一，就是一次要求太多。如果模型同時寫出大範圍測試組與大塊實作，就把範圍縮小：

Pick one failing test that captures the first slice of behavior. Do not implement the whole feature yet.

這樣才能維持 test-driven-development 的循環完整性。

要求說明為什麼第一個測試是正確的

請要求代理說明：

• 為什麼這個測試是最小但有用的切片
• 預期會出現什麼精確失敗
• 為什麼這個失敗能證明該行為目前缺失

這麼做能提升品質，因為它會在實作開始前，先把隱含假設攤開來。

及早留意 anti-patterns

最常見的品質下滑包括：

• 測的是 mocks，不是行為
• 在正式程式碼裡加入只給測試用的方法
• 先寫會通過的測試，卻稱之為 TDD
• 寫出緊貼實作細節的斷言
• 測試一變綠就跳過重構步驟

只要看到其中一種，就先停止這一輪，要求重寫正確的第一個測試，而不是在錯誤基礎上繼續補丁。

明確提供 repository 慣例

當你清楚告訴這個 skill 以下資訊時，結果通常會更好：

• 測試命名慣例
• 測試放在哪裡
• fixture 的使用模式
• mocking policy
• 偏好的 assertion style

因為這個 repository 本身提供的支援資料偏輕量，所以這些在地慣例會實質影響產出品質。

在第一輪輸出後持續迭代

拿到初版結果後，不要只說「再多做一點」。請改用有方向的追問：

• Can you make the failing test narrower?
• Is this failure due to setup or missing behavior?
• Can we remove this mock and test real behavior instead?
• What is the minimum code needed to pass?
• What refactor is now safe with tests green?

這是在實務上提升 test-driven-development skill 效果的最高槓桿做法：讓代理一直待在循環裡，而不是任由它往前亂跳。

對例外情況保留人工判斷

這個 skill 的設計本來就刻意嚴格。這是它的優勢，但也可能被過度套用。如果任務只是純設定變更、更新生成程式碼，或一次性原型，請先判斷完整 TDD 是否值得那個成本。把這個 skill 用在「test-first 順序真的會改善決策品質」的地方，效果會比「凡是能套就套」更好。