目錄
- PART I: 入門
- Chap 1: 單元測試基礎
- Chap 2: 第一個單元測試
- PART II: 核心技術
- Chap 3: 透過虛設常式解決依賴問題
- Chap 4: 使用模擬物件驗證互動
- Chap 5: 隔離（模擬）框架
- Chap 6: 深入了解隔離框架
- PART III: 測試程式碼
- Chap 7: 測試階層和組織
- Chap 8: 好的單元測試的支柱
- Chap 9: 在組織中導入單元測試
- Chap 10: 遺留程式碼
- Chap 11: 設計與可測試性
前言
遺留程式碼的影響：
- 很難給已經存在的程式碼撰寫測試程式
- 幾乎不可能重構現有程式碼
- 有些人不想修改設計
- 工具使用不便
- 難以決定從什麼地方開始進行測試
一、從哪裡開始加入測試
假設要測試既有組件，那麼我們先需要處理組件優先級，影響組件優先級的有以下幾點：
- 邏輯複雜度：組件中邏輯的數量，如：巢狀 if, switch, 或遞迴
- 依賴程度：組件中依賴項的數量
- 優先級：組件在專案中的優先等級
我們通常可以先忽略低於邏輯複雜度標準的組件，也就是 Person 和 ConfigManager。剩下的就是較困難的且重要的，基本上分成兩種方式：
- 選擇複雜度較高，但是容易測試
- 選擇複雜度較高，且較難測試
二、決定選擇策略
- 先易後難策略
- 優點：初期速度很快
- 缺點：隨著時間推移，剩下的組件越來越難測試，又時限迫在眉睫，每個人壓力都很大
- 建議：如果你的團隊對單元測試還不熟悉，可以從容易測試的組件開始測試。
- 先難後易策略
- 優點：時間拉長，測試越來越順利、快
- 缺點：一開始可能會花一整天甚至更多時間處理，但會隨著重構，後面越發便捷
- 建議：只有當你的團隊有單元測試技術方面的雞驗時，較適合使用先難後易的策略
三、在重構前撰寫整合測試
為了確保重構不會破壞原有功能，一個較為實際的方法是對產品程式碼撰寫整合測試。
小結
這章介紹了第一次接觸遺留程式碼時應該如何切入，重點在於：了解各個組件之間的依賴數量、邏輯複雜度、優先級。
如果團隊測試經驗少，應由容易測試的組件著手，如果團隊經驗豐富，則建議由難以測試的組件開始進行。
