面對 legacy 產品，在時間資源有限的情況下，該挑哪些功能來進行測試才適合，是實務上最重要的一件事。
在《單元測試的藝術》第十章的 [表 10-1] 依據組件類型來舉例，針對邏輯複雜度、依賴數量、在專案中的優先級幾個維度來分析，本文則針對這幾個維度進行補充說明。
可以從一些靜態分析數據來評估，哪一些測試比較好做以及有比較高的價值！
複雜度
複雜度越高，代表幾件事：
- 人腦不好判讀，也就容易寫錯，尤其是 condition branch 的部分，bool 一直都是口是心非最常出現的地方。
- 複雜度高，也很容易是職責攪在一起的地方，職責攪在一起就代表，只要某個職責需求有所變化，這一段程式碼就會被影響到，進而需要進行修改與調整。而只要有異動和調整，就可能會把原本是對的，改成是錯的。所以為這建立測試程式，可以讓後續的回歸測試時間縮得更短。如果要改的就是這一大段複雜的方法，那為他撰寫好完整的測試程式，後續調整或維護的人員，就可以從測試案例的 scenario 瞭解這段程式碼究竟代表著什麼樣的需求與期待。需求要調整時，先從測試案例著手，而不是直接動手改 production code。
- 複雜度高，如前面講的，通常不好維護、不好讀、職責攪在一起，因此也是重構的優先候選。要重構前，要先建立測試，才能確保程式碼不會因為重構的修改而導致執行結果不如預期。
外部依賴
外部依賴的部分，代表的是耦合性。耦合性越強，代表彈性越弱，代表越容易牽一髮動全身，代表單元測試的可測試性薄弱。因此：
- 外部依賴越多，可測試性越低，撰寫單元測試程式的成本與時間越高。（重構解耦完才能撰寫 isolated unit test）
- 若單元測試成本過高，且環境允許使用整合測試，那就適合直接使用整合測試。有了整合測試保護後，接著只要時間允許，需求需要，隨時可以對程式重構進行解耦，解耦完成就代表外部依賴減少了，自然撰寫 isolated unit test 的成本就降低了。
總結
整體投資報酬比依序是：複雜度高且外部依賴低 > 複雜度高且外部依賴高 > 複雜度低且外部依賴低 > 複雜度低且外部依賴高
有個簡單的例外情況：線上出錯了的程式，優先順序最高。
最後，舉幾個例子：
- 複雜度高、外部依賴低：很多純粹邏輯驗證的 validation 屬於這一類。例如統一編號/身份證字號的驗證、不需要太多外部依賴的商業邏輯驗證（例如毛利率要>n%, 訂單金額不可以小於0、某些長度不可以過長、編碼規則驗證等等）。這類 case 很容易出錯，但其實測試成本極低。
- 複雜度高、外部依賴高：business/domain layer 的物件居多。重點在於職責怎麼切分，接著才是有哪一些是值得解耦的。（完全介面導向+DI的設計，是有點 over design 但不失為一個簡單的 policy）
- 複雜度低、外部依賴高：如果是正常的，那大概就是一些 pattern 的中間層產物，例如 adpater、model mapping、proxy 類型的。這類即使不寫測試，造成的影響不大，原因是當其他該寫測試的都寫了，一旦 runtime 執行出錯，馬上就可以找到問題可能就在這些中介層或外部依賴。另外一類正常的，就是貧血的 Dao 物件，不帶商業邏輯，但會與外部資料來源相依，例如外部的 web service, database, file 等 persistence 資源。這類型因為往往不帶邏輯，而對需求來說，想驗證的也是 to end 的 result，所以撰寫整合測試的價值優於單元測試。
- 複雜度低、外部依賴低：這比較常出現在非 public/internal 的 function，就讓 public 的 test cases 去 cover 即可。如果這樣的方法也是 public 的，有時間就幫他寫測試，沒時間的話，因為他沒啥邏輯，出錯的機率低，可以等到需求異動時再來補測試案例即可。（當然，如果你是 TDD，根本就不會有這些問題）
blog 與課程更新內容，請前往新站位置：http://tdd.best/
