前言：回到 Day 01 立的那句話

Day 01 立下這個系列貫穿全篇的主題句：不可控依賴不代表不能測，關鍵是找到每種依賴各自的替身策略。走完第四部七天，是時候把這句話兌現成一張具體的對照表。

今日目標

• 把網路、檔案系統、加密三種依賴的替身策略收斂成一張總表
• 看清楚三種策略背後其實共用同一個判斷邏輯
• 為系列總結預告：這套紀律换成別的專案、別的語言，還通用嗎

三種依賴，三種替身策略

三種策略背後，其實是同一個判斷邏輯

表面上這三種策略用的技巧完全不同（手刻類別、第三方函式庫、反向產生資料），但拆解到底層，其實都在回答同一個問題：「這個依賴對外承諾的行為邊界是什麼？替身只要精確符合這個邊界，被測試的程式碼就分辨不出來自己面對的是真的還是假的。」

• 網路：邊界是「HTTP client 的公開介面」（get()、read()、headers）
• 檔案系統：邊界是「Python 標準函式庫的檔案操作介面」（open()、os.path）
• 加密：邊界是「金鑰 + 演算法 → 密文/明文」這組明確的數學關係

Day 28 講過「mock 太底層會讓測試脆弱」，本質上就是在提醒：替身要包在這條邊界上，不能包到邊界背後的實作細節。

這張表格不是清單，是一個可以套用到其他依賴的方法

如果之後遇到這三種以外的不可控依賴（例如系統時間、隨機數、第三方支付閘道），同樣的判斷邏輯依然適用：先找出這個依賴對外承諾的穩定邊界，再想辦法在那條邊界上做出一個行為精確吻合的替身，而不是各自發明一套處理方式，或者乾脆放棄測試、只能靠人工檢查。

今日重點回顧

• 網路、檔案系統、加密，各自對應手刻 mock、pyfakefs、反向產生 fixture 三種替身策略
• 三種策略背後是同一個判斷邏輯：找出依賴對外承諾的穩定邊界，在那條邊界上做替身
• 這個判斷邏輯可以套用到任何其他不可控依賴，不是三個各自獨立的技巧

明日預告

明天是系列總結：這套紀律，换成任何語言、任何專案都通用嗎？