【單元測試的藝術】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, 或遞迴
  • 依賴程度:組件中依賴項的數量
  • 優先級:組件在專案中的優先等級

alt text

我們通常可以先忽略低於邏輯複雜度標準的組件,也就是 Person 和 ConfigManager。剩下的就是較困難的且重要的,基本上分成兩種方式:

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

二、決定選擇策略

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

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

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


小結

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

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

#Unit Test #單元測試的藝術