【單元測試的藝術】Chap 10: 遺留程式碼

目錄

• 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。剩下的就是較困難的且重要的，基本上分成兩種方式：

1. 選擇複雜度較高，但是容易測試
2. 選擇複雜度較高，且較難測試

二、決定選擇策略

1. 先易後難策略
   • 優點：初期速度很快
   • 缺點：隨著時間推移，剩下的組件越來越難測試，又時限迫在眉睫，每個人壓力都很大
   • 建議：如果你的團隊對單元測試還不熟悉，可以從容易測試的組件開始測試。
2. 先難後易策略
   • 優點：時間拉長，測試越來越順利、快
   • 缺點：一開始可能會花一整天甚至更多時間處理，但會隨著重構，後面越發便捷
   • 建議：只有當你的團隊有單元測試技術方面的雞驗時，較適合使用先難後易的策略

三、在重構前撰寫整合測試

為了確保重構不會破壞原有功能，一個較為實際的方法是對產品程式碼撰寫整合測試。

小結

這章介紹了第一次接觸遺留程式碼時應該如何切入，重點在於：了解各個組件之間的依賴數量、邏輯複雜度、優先級。

如果團隊測試經驗少，應由容易測試的組件著手，如果團隊經驗豐富，則建議由難以測試的組件開始進行。