【單元測試的藝術】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 #單元測試的藝術







你可能感興趣的文章

物件導向基礎與 prototype

物件導向基礎與 prototype

The introduction and difference between class component and function component in React

The introduction and difference between class component and function component in React

swap用法

swap用法






留言討論





2
2
2