springboot-tdd

springboot-tdd 技能概覽

springboot-tdd 是一個聚焦於 Spring Boot 測試優先流程的技能，適合用 JUnit 5、Mockito、MockMvc、Testcontainers 和 JaCoCo 來建立或修改後端程式碼。它特別適合需要可重複方法來新增功能、修正 bug 或重構程式，同時維持高覆蓋率與清楚測試意圖的開發者與代理。

springboot-tdd 的用途

springboot-tdd 技能能幫你把像「新增一個 endpoint」或「修正這個 service bug」這類需求，轉成可執行的測試優先實作計畫。它真正的工作，是把 TDD 流程講清楚：先寫出失敗的測試，再做最小修改，最後安全地重構。

最適合與不適合的情境

當你在處理 service 邏輯、controller 行為、持久化規則與安全性檢查，且回歸風險需要被嚴格控制時，springboot-tdd 很適合。相較之下，它對前端工作、臨時性的除錯，或不太需要測試優先步驟的大型架構重設，適配度就較弱。

為什麼這個技能不一樣

和一般的提示詞相比，springboot-tdd 提供的是 Spring Boot 專用的測試技術棧，以及更清楚的判斷路徑，幫你區分 unit test、web-layer test 與 integration test。它的主要價值在於，減少你對「先測什麼」以及「怎麼讓實作和測試保持一致」的猜測。

如何使用 springboot-tdd 技能

安裝 springboot-tdd 技能

使用目錄安裝器把這個技能加入你的 Claude Code 設定：

npx skills add affaan-m/everything-claude-code --skill springboot-tdd

這就是 springboot-tdd 的安裝步驟；安裝完成後，當你的任務需要在 Spring Boot repository 中做測試驅動變更時，就可以使用這個技能。

先讀對的檔案

先從 SKILL.md 開始，理解核心流程；如果你正在處理的 repo 裡有連結的專案文件或輔助檔，再接著檢視。對這個技能來說，最值得先看的通常是 workflow 區段加上 test 範例，因為它們會示範預期的測試風格，以及 unit test 和 web-layer test 的邊界。

給技能一個具體的測試目標

springboot-tdd 最好用的方式，是你先提供明確的程式路徑與預期行為。好的輸入例如：

• “Add a createMarket service method that rejects blank names and persists valid requests.”
• “Write a controller test for GET /api/markets returning an empty page and a 200 response.”
• “Refactor this repository lookup without changing current behavior.”

像「改善測試」或「讓它更穩定」這種模糊指令，會逼技能去猜驗收標準。

依照 TDD 流程順序執行

使用這個技能時，應先規劃測試，再寫程式，最後重構。實際可行的 springboot-tdd 流程通常會產出：

1. 一個失敗的 unit test 或 web-layer test，
2. 能滿足該測試的最小實作，
3. 測試通過後的整理與清理，
4. 用 JaCoCo 進行覆蓋率檢查。

如果變更跨越多個層次，就應分開處理測試選擇，不要硬把所有東西塞進同一種測試裡。

springboot-tdd 技能 FAQ

springboot-tdd 只適合綠地專案嗎？

不適合。springboot-tdd 對既有的 Spring Boot 服務尤其有用，因為 bug 修正與重構在改碼前就能先補上回歸測試。它當然也適合新程式碼，但並不只限於新專案。

它和一般提示詞有什麼不同？

一般提示詞也可以描述 TDD，但 springboot-tdd 提供的是可重複使用的 Spring Boot 測試決策流程，包括何時使用 Mockito、MockMvc，以及如何落實覆蓋率要求。這通常代表較少來回溝通，也比較少出現空泛的測試建議。

對初學者友善嗎？

如果你已經看得懂基本的 Java 測試，那答案是肯定的。這個技能對 Spring Boot 團隊來說算是友善，因為它提供一條實用路徑；但使用者仍需要提出清楚的行為目標，並理解自己專案的測試設定。

它適合 Test Automation 嗎？

可以，當你的 Test Automation 目標是可靠的後端驗證，而不是 UI 腳本時，springboot-tdd 會是好選擇。若你需要瀏覽器自動化、Spring Boot 之外的 contract 工具，或非 Java 的測試技術棧，它就比較不適合。

如何改善 springboot-tdd 技能

先把行為講清楚，再要求產生程式

最好的 springboot-tdd 結果，來自精準的驗收標準：輸入、輸出、邊界情況與失敗條件都要具體。不要只說「幫訂單加測試」，而是要說「拒絕重複的 order ID，衝突時回傳 409，並保持 service 的 idempotent」。

選對測試層級

常見的失敗模式，是明明 unit test 會更快、更清楚，卻要求 integration test；或是情況相反。要提升 springboot-tdd 的輸出品質，請直接說明這次變更碰到的是純商業邏輯、HTTP 行為、資料庫存取，還是外部相依。

提供會影響實作的限制條件

請提到 framework 版本、資料庫設定、安全性 filter，以及任何會影響 Testcontainers 或 CI 的限制。這些細節能幫 springboot-tdd 避免脆弱的假設，產出更符合你專案、而不是教科書範例的測試。

從失敗測試逐步迭代到最終形狀

如果第一次輸出太大範圍，就先要求更窄的測試切片，等第一個測試通過後再擴充。最快的改善路徑通常是：一個情境、一個 test class、一個行為變更，然後再做第二輪來補邊界案例與覆蓋率缺口。