測試驅動開發
Test-Driven Development — Kent Beck
🔁 紅 → 綠 → 重構
🎯 什麼情境該想到我
當你想實作一個功能、又想讓它天然可測、乾淨、不易出錯時。
⚙️ 怎麼用（小步循環）
- 🔴 紅：先寫一個描述「你要的行為」的測試 —— 它現在會失敗（因為還沒實作）。
- 🟢 綠：用最快、最簡單的方式讓測試通過（可以先寫死、先醜，重點是綠燈）。
- ♻️ 重構：在綠燈保護下，去除重複、整理結構（見 工具-提煉函式）——每步都保持綠。
- 回到步驟 1，加下一個測試。步子小到幾乎不可能出錯；出錯就把步子切更小。
🧪 我實際套用的紀錄
- 2026-07-15：（待填）
⚠️ 注意
- 別跳過重構那步（只紅綠不重構＝債越積越多）；也別在紅燈時做重構。
🔗 相關工具
- 工具-測試先行的設計 —— 為什麼要這樣跑，這張講節奏，它講先寫測試帶來的設計效果
- 工具-小步重構 —— 第三步 Refactor 的操作細節，在綠燈保護下一次改一小塊
- 工具-提煉函式 —— Refactor 階段最常用的那一招
🔴 紅 先寫一個描述「要什麼行為」的測試，它現在會失敗
🟢 綠 用最快、最簡單的方式讓它通過（可以先醜、先寫死）
♻️ 重構 在綠燈保護下去除重複、整理結構，每步都保持綠
👣 小步前進
每步小到「幾乎不可能出錯」 隨時都有綠燈保護，出錯範圍極小
不確定就把步子切更小 步伐大小是可調節的旋鈕，不是固定值
「先讓它動，再讓它對，最後讓它快。」 程式碼在「可運作」與「乾淨」兩態間小步移動
🟩 讓測試變綠的策略
假實作 Fake It 先直接寫死回傳值讓燈變綠，再逐步一般化
三角測量 Triangulation 加第二、第三個例子，逼出真正的通用解
顯明實作 Obvious Implementation 答案很明顯時就直接寫對，別繞路
🎨 TDD 是設計工具
🎯 什麼情境該想到我
當你的程式「很難寫測試」（依賴一堆、要 mock 一大票），或想讓設計更清楚時。難測，往往是設計不良的訊號。
⚙️ 怎麼用
- 先寫測試 = 先從「使用者角度」設計介面：你被迫先想「這東西怎麼被呼叫最順」，介面自然變好用。
- 難測就是設計警報：如果要測某段得建構一堆相依 → 代表耦合太緊，該解耦（見 工具-打破依賴以便測試、工具-針對介面編程）。
- 讓測試逼出低耦合：依賴用注入、對介面編程，程式自然可測、可替換。
- 測試即活文件：讀測試就知道這段程式該有什麼行為。
🧪 我實際套用的紀錄
- 2026-07-15：（待填）
⚠️ 注意
- 目標是「設計驅動」，不是「為了 100% 覆蓋率而測」；測試是設計的副產品與保護網。
🔗 相關工具
- 工具-紅綠重構循環 —— 節奏卡，這張講「為什麼先寫測試」，它講「一輪怎麼跑」
- 工具-打破依賴以便測試 —— 面對舊碼時的補救手法，先行做不到就只能事後拆依賴
- 工具-針對介面編程 —— 讓測試好寫的設計手段，依賴介面才能替換成測試替身
先寫測試＝從使用端設計介面 被迫先想「這東西怎麼被呼叫最順」
難測就是設計警報 要 mock 一大票 → 耦合太緊，該解耦
測試即規格與活文件 讀測試就知道這段程式該有什麼行為