🎯 什麼情境該想到我
當你的程式「很難寫測試」（依賴一堆、要 mock 一大票），或想讓設計更清楚時。難測，往往是設計不良的訊號。
⚙️ 怎麼用
- 先寫測試 = 先從「使用者角度」設計介面：你被迫先想「這東西怎麼被呼叫最順」，介面自然變好用。
- 難測就是設計警報：如果要測某段得建構一堆相依 → 代表耦合太緊，該解耦（見 工具-打破依賴以便測試、工具-針對介面編程）。
- 讓測試逼出低耦合：依賴用注入、對介面編程，程式自然可測、可替換。
- 測試即活文件：讀測試就知道這段程式該有什麼行為。
🧪 我實際套用的紀錄
- 2026-07-15：（待填）
⚠️ 注意
- 目標是「設計驅動」，不是「為了 100% 覆蓋率而測」；測試是設計的副產品與保護網。
🔗 相關工具
- 工具-紅綠重構循環 —— 節奏卡，這張講「為什麼先寫測試」，它講「一輪怎麼跑」
- 工具-打破依賴以便測試 —— 面對舊碼時的補救手法，先行做不到就只能事後拆依賴
- 工具-針對介面編程 —— 讓測試好寫的設計手段，依賴介面才能替換成測試替身