tdd

tdd 技能概覽

tdd 是一個用於以 red-green-refactor 迴圈來開發功能與修復 bug 的 Test-Driven Development 技能。它最適合想要一份實用的 tdd 指南、而且重視測試與行為而非實作保持一致的工程師。如果你正在處理一個常常需要重構、介面很重要、而且脆弱測試正在拖慢你速度的 codebase，這個技能可以幫你寫出能撐過變動的測試。

它要完成的核心工作很單純：把一個粗略的功能想法，轉成一連串安全、可小步驗證的操作。tdd 技能特別適合測試自動化工作、偏整合式的測試，以及那些因為邊界更清楚而受益的程式碼。它最強烈的主張是：透過公開介面測試，只在真正的系統邊界才進行 mock。

tdd 的用途

當你想要用 test-first 的工作流程來處理新行為、bug 修正，或需要保護網的重構時，就該用 tdd。如果你已經知道預期結果，但還不確定最乾淨的實作路徑，它就很適合。

這個 tdd 技能有什麼不同

這個 repo 不只是「先寫測試」而已。它推的是一套具體的紀律：避免水平切片、偏好以行為為中心的測試，並設計成容易測試的介面。當你需要的是耐用的測試，而不是快但脆弱的測試時，tdd 技能會比一般通用提示更有用。

什麼情況下 tdd 不適合

如果你只是要一個快速的一次性 unit test、丟著就用的 script，或是那種大量 mock 內部呼叫的驗證方式，這大概不是對的工具。這個技能是為了你預期會持續重構的軟體而設計的，在那種情境下，測試品質比測試數量更重要。

如何使用 tdd 技能

安裝並載入這個技能

先用目錄中的安裝指令完成 tdd install 步驟，接著先打開 SKILL.md。之後再閱讀 tests.md、mocking.md、interface-design.md、refactoring.md 和 deep-modules.md，這些才是真正影響輸出品質的規則。

給技能的是行為，不是解法

最好的 tdd usage 會從使用者可見的結果、輸入，以及預期輸出開始。強的提示詞長這樣：

• “Add checkout validation so invalid carts return a clear error and valid carts complete payment”
• “Fix the bug where duplicate emails create two accounts”
• “Write tests for a retry flow against a payment API, using the public service interface”

弱的提示詞長這樣：

• “Write tests for checkout”
• “Make this module more testable”
• “Mock the database and verify the function was called”

遵循 red-green-refactor 迴圈

先從最小、可觀察的行為開始，寫一個會失敗的測試來證明它，再實作最少的程式碼讓它通過，然後在保持測試綠燈的前提下重構。不要先一次批量寫完所有測試、之後才一次補實作；這個技能明確反對水平切片，因為那樣很容易做出想像中的行為，而不是已經被測試過的行為。

先讀這些檔案

若要實際執行，請優先閱讀：

• SKILL.md：理念與工作流程
• tests.md：好的與不好的測試模式
• mocking.md：只在邊界做 mock
• interface-design.md：讓程式碼更好測試
• refactoring.md：第一次通過後還能改進什麼

tdd 技能常見問答

tdd 只適合 unit test 嗎？

不是。這個 tdd 技能偏好透過公開介面的整合式測試，這也讓它在測試自動化與行為測試上，往往比只做孤立 unit test 的做法更合適。

我需要把所有東西都 mock 起來嗎？

不用。這份 tdd guide 的核心規則之一，是只在系統邊界做 mock，例如外部 API、時間、隨機性，或有時候是檔案系統與資料庫。不要只是為了讓測試過關，就把自己的 modules 全部 mock 掉。

初學者可以用 tdd 嗎？

可以，只要他們能清楚描述預期行為。最大的學習曲線不是語法，而是如何選對邊界，以及避免寫成實作細節測試。

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

一般提示詞可能只會產生勉強能編譯的測試。tdd 技能則更有立場：它會推動以行為為先的測試、小步增量，以及能讓測試在重構期間保持穩定的介面設計。

如何改進 tdd 技能

先把輸入寫得更銳利

當你把行為、邊界和限制一起寫進去時，tdd 的結果通常會更好。比如不要只說“make this testable”，而是說“build a retryable email sender that uses a real service wrapper, but mock time and the external provider”。

注意常見的失敗模式

最常見的錯誤包括過度 mock、測試 private methods，以及寫出描述程式怎麼運作而不是使用者看到什麼的測試。如果第一版看起來太偏實作，請重新改寫提示詞，把 public API 和可觀察結果直接點出來。

從測試回推設計再迭代

拿到第一版輸出後，利用失敗訊息去改善介面設計：讓參數更小、回傳值更清楚、side effects 更少。如果程式碼還是很難測，問題可能在 API 形狀，不一定是測試本身。

綠燈後再要求重構目標

當行為已經被覆蓋後，再請技能找出重複、過長方法、淺層 modules、feature envy，或 primitive obsession。這就是 tdd 技能額外有價值的地方：它能幫你從「測試通過」走向更乾淨、也會一直容易測試的設計。