- Published on
從理論到實踐:Claude Code TDD Plugin 介紹

從理論到實踐的演進
還記得先前撰寫的《AI Coding 下的 TDD 實踐》這篇文章嗎?在那篇文章中,我們深入探討了在 AI Coding 時代,TDD 如何幫助開發者保持對程式碼的掌控權
當時為了在 TDD 分享活動中進行 demo,我開發了兩種不同的 TDD 開發方式。那時候這些只是存放在本機的 local command,主要用於演示。經過一段時間的使用和調整後,我決定將這些實踐方法公開為 Claude Code plugin,讓更多開發者可以在實際專案中使用
這篇文章將介紹這個 plugin 的安裝和使用方式,讓你能夠立即在自己的專案中實踐 AI 時代的 TDD
為何需要這個 Plugin
在之前的文章中,我們討論了 AI Coding 帶來的核心挑戰
失控感的來源
當我們請 AI 幫忙撰寫程式碼時,常常會遇到以下問題
- AI 可能產生過度設計的解決方案
- 程式碼的實作細節與我們的預期不符
- 難以理解 AI 為何選擇某種實作方式
- 失去對程式碼演進方向的掌控
TDD 在 AI Agent 時代的新價值
TDD 不僅僅是一種測試方法,在 AI 時代更是一種掌控工具
- 控制實作範圍:透過測試案例明確定義 AI 應該實作什麼功能
- 引導發展方向:每個測試都是一個明確的目標,引導 AI 朝正確方向前進
- 保持掌控權:開發者決定下一步要實作什麼,而不是讓 AI 自由發揮
- 建立理解橋樑:透過測試理解程式碼的行為,即使是 AI 產生的程式碼
但光有理論還不夠,我們需要具體的工具來支持這些實踐。這就是為什麼我將分享活動中使用的方法整理成 plugin 的原因
Plugin 介紹:兩種 TDD 方法
這個 plugin 提供了兩種不同的 TDD 開發方法,每種方法都有其獨特的哲學和適用場景
Kent Beck TDD
核心哲學
Kent Beck 的 TDD 方法強調有機演進和探索式開發。這種方法認為好的設計應該從簡單的測試中自然浮現,而不是事先規劃
主要特色
- 從最簡單開始:從最簡單的測試案例開始,逐步增加複雜度
- 快速循環:Red-Green-Refactor 的循環非常快速,可能幾分鐘就完成一輪
- 接受臨時實作:在 Green 階段可以接受硬編碼或臨時實作,透過重構來改善
- 最小文件:只維護一份
journey.md記錄開發旅程
適用場景
- 探索新的技術領域或問題空間
- 需求還不是很明確的情況
- 個人開發或小型專案
- 想要快速驗證想法或概念
命令流程
/kb-start # 開始新的 TDD 流程,初始化專案結構
/kb-red # 撰寫一個失敗的測試
/kb-green # 用最簡單的方式讓測試通過
/kb-refactor # 重構程式碼,改善設計
/kb-review # 檢視當前的開發進度和下一步
Test-First TDD
核心哲學
Test-First TDD 採用更結構化、計畫驅動的開發方式。這種方法強調預先規劃和完整的文件記錄
主要特色
- 預先規劃:從需求文件開始,規劃所有的測試案例
- 完整文件:維護四份文件(需求、測試案例、開發日誌、檢查清單)
- 繁體中文註解:所有程式碼都包含完整的繁體中文註解
- 內建驗證:提供完整性驗證機制,確保所有測試案例都已實作
- 團隊協作:完整的文件使團隊成員更容易理解專案狀態
適用場景
- 需求已經明確的專案
- 團隊協作開發
- 需要完整文件記錄的場合
- 大型或長期維護的專案
命令流程
/tf-requirements # 撰寫詳細的需求文件
/tf-testcases # 根據需求規劃所有測試案例
/tf-red # 撰寫一個失敗的測試
/tf-green # 實作功能讓測試通過
/tf-refactor # 重構程式碼
/tf-verify # 驗證所有測試案例是否完成
兩種方法的對比
以下表格幫助你快速了解兩種方法的差異
| 維度 | Kent Beck TDD | Test-First TDD |
|---|---|---|
| 規劃方式 | 逐步演進,邊做邊想 | 預先規劃,計畫驅動 |
| 文件量 | 最小(1份 journey.md) | 完整(4份文件) |
| 適用場景 | 探索/個人開發 | 團隊協作/明確需求 |
| 命令數 | 5個命令 | 6個命令 |
| 學習曲線 | 較陡峭,需要經驗判斷 | 較平緩,有明確步驟 |
| 彈性 | 高度彈性,可隨時調整 | 結構化,變更需要更新文件 |
| 語言 | 英文為主 | 繁體中文註解 |
選擇建議
不確定該選哪一種?可以這樣思考
- 如果你在探索一個新想法,先用 Kent Beck TDD
- 如果你要開始正式專案,使用 Test-First TDD
- 其實兩種方法可以在專案的不同階段互補使用
安裝與使用指南
安裝步驟
使用 Claude Code 的 plugin 系統安裝非常簡單
# 步驟 1: 加入 marketplace
/plugin marketplace add cashwu/claude-code-tdd-marketplace
# 步驟 2: 安裝 plugin (可以選擇安裝一個或兩個)
/plugin install kent-beck-tdd
/plugin install test-first-tdd
建議兩個都安裝,這樣可以根據不同情況選擇最適合的方法
Kent Beck TDD 使用流程
第一步:開始
/kb-start
系統會初始化專案結構,建立 journey.md 文件
第二步:Red-Green-Refactor 循環
# 1. 寫一個失敗的測試
/kb-red
# 2. 用最簡單的方式讓測試通過
/kb-green
# 3. 重構程式碼
/kb-refactor
# 重複這個循環
隨時檢視進度
/kb-review
這個命令會幫你回顧目前的開發旅程,並建議下一步該做什麼
Test-First TDD 使用流程
第一步:定義需求
/tf-requirements
詳細描述你要實作的功能需求
第二步:規劃測試案例
/tf-testcases
根據需求文件,規劃所有需要的測試案例
第三步:Red-Green-Refactor 循環
# 1. 選擇一個測試案例,撰寫失敗的測試
/tf-red
# 2. 實作功能讓測試通過
/tf-green
# 3. 重構程式碼
/tf-refactor
# 重複直到所有測試案例完成
驗證完整性
/tf-verify
這個命令會檢查是否所有規劃的測試案例都已經實作完成
實際範例
在 GitHub Repository 中,我提供了兩個 Tennis Kata 的實作範例
examples/kent-beck-tennis-kata:展示 Kent Beck TDD 的開發過程examples/test-first-tennis-kata:展示 Test-First TDD 的開發過程
這兩個範例實作同樣的功能,但使用不同的方法,你可以比較兩種方法在實際應用中的差異
實踐建議
何時使用 Kent Beck TDD
如果你遇到以下情況,Kent Beck TDD 可能是更好的選擇
探索新領域
當你在學習一個新的程式語言、框架或技術時,你可能不確定最佳的實作方式。這時候 Kent Beck TDD 的探索式開發非常適合
需求不明確
有時候我們只有一個模糊的想法,不確定最終的樣子。透過撰寫簡單的測試,讓設計自然浮現,比預先規劃更有效
快速驗證
想要快速驗證一個想法是否可行?Kent Beck TDD 的快速循環可以讓你在短時間內得到反饋
個人專案
如果只有你一個人開發,不需要向團隊成員解釋設計決策,最小化的文件可以讓你專注在程式碼本身
何時使用 Test-First TDD
以下情況 Test-First TDD 會是更好的選擇
需求明確
當你已經清楚知道要實作什麼功能,所有的使用情境都已經定義好,預先規劃測試案例可以確保不遺漏任何情況
團隊協作
在團隊開發中,完整的文件可以幫助團隊成員理解
- 目前實作了哪些功能
- 還有哪些功能待實作
- 為什麼做某些設計決策
長期維護
對於需要長期維護的專案,完整的需求文件和測試案例規劃,可以幫助未來的維護者快速理解專案
品質要求高
Test-First TDD 內建的驗證機制,可以確保所有規劃的測試案例都有實作,不會遺漏重要的測試
互補使用策略
其實這兩種方法不是互斥的,而是可以互補使用
探索階段用 Kent Beck
在專案初期,需求還不是很明確時,使用 Kent Beck TDD 快速探索和驗證想法
正式開發用 Test-First
當方向確定後,使用 Test-First TDD 進行結構化的開發,確保品質和完整性
重構時切換
當發現需要大幅重構時,可以暫時切換到 Kent Beck TDD,探索新的設計方向
學習曲線考量
如果你是 TDD 初學者,建議先從 Test-First TDD 開始。它的結構化步驟可以幫助你建立 TDD 的思維模式。當你更熟悉 TDD 後,再嘗試 Kent Beck TDD 的探索式開發
常見問題
這兩種方法可以在同一個專案中混用嗎
可以,但建議在同一個功能模組內使用同一種方法。你可以在不同的模組使用不同的方法
我已經有現有的測試程式碼,可以使用這個 plugin 嗎
可以。你可以從 /kb-review 或 /tf-verify 開始,讓系統分析現有的測試,然後繼續開發
使用這個 plugin 需要特別的專案結構嗎
不需要。plugin 會適應你現有的專案結構。不過建議遵循各語言的慣例(例如 C# 的測試專案、Python 的 tests 目錄等)
我可以客製化這些命令嗎
當然可以。這些 plugin 都是開源的,你可以 fork 後根據自己的需求調整
結語:完整的 TDD 實踐路徑
讓我們回顧一下這個完整的學習路徑
第一步:理解為什麼
在《AI Coding 下的 TDD 實踐》這篇文章中,我們探討了
- TDD 的本質是什麼
- 在 AI 時代面臨什麼挑戰
- 為什麼 TDD 在 AI 時代反而更重要
第二步:掌握怎麼做
這篇文章提供了具體的工具和方法
- 兩種不同的 TDD 實踐方式
- 清楚的使用指南
- 實際的範例程式碼
第三步:實際行動
現在輪到你了。建議你
- 安裝 plugin,實際試用看看
- 選擇一個小型的 kata 或練習題開始
- 體會兩種方法的差異
- 在實際專案中應用
TDD 不只是技術,更是思維方式
在 AI 可以快速產生大量程式碼的時代,TDD 幫助我們保持對程式碼的掌控權。它不是要阻礙 AI 的生產力,而是要引導 AI 朝我們期望的方向發展
透過這些工具,我們可以在享受 AI 帶來的開發速度的同時,仍然保持對程式碼品質和設計的掌控
持續演進
這些 plugin 還在持續改進中。如果你在使用過程中有任何建議或發現問題,歡迎在 GitHub Repository 提出 issue 或 pull request
讓我們一起在 AI 時代,找到更好的開發方式
支持創作
如果這篇文章對您有幫助,歡迎透過 贊助連結 支持我持續創作優質內容。您的支持是我前進的動力!
圖片來源:AI 產生
