[遛書]《單元測試的藝術》測試可行性表

面對 legacy 產品,在時間資源有限的情況下,該挑哪些功能來進行測試才適合,是實務上最重要的一件事。

在《單元測試的藝術》第十章的 [表 10-1] 依據組件類型來舉例,針對邏輯複雜度、依賴數量、在專案中的優先級幾個維度來分析,本文則針對這幾個維度進行補充說明。

可以從一些靜態分析數據來評估,哪一些測試比較好做以及有比較高的價值!

複雜度

複雜度越高,代表幾件事:

  1. 人腦不好判讀,也就容易寫錯,尤其是 condition branch 的部分,bool 一直都是口是心非最常出現的地方。
  2. 複雜度高,也很容易是職責攪在一起的地方,職責攪在一起就代表,只要某個職責需求有所變化,這一段程式碼就會被影響到,進而需要進行修改與調整。而只要有異動和調整,就可能會把原本是對的,改成是錯的。所以為這建立測試程式,可以讓後續的回歸測試時間縮得更短。如果要改的就是這一大段複雜的方法,那為他撰寫好完整的測試程式,後續調整或維護的人員,就可以從測試案例的 scenario 瞭解這段程式碼究竟代表著什麼樣的需求與期待。需求要調整時,先從測試案例著手,而不是直接動手改 production code。
  3. 複雜度高,如前面講的,通常不好維護、不好讀、職責攪在一起,因此也是重構的優先候選。要重構前,要先建立測試,才能確保程式碼不會因為重構的修改而導致執行結果不如預期。

外部依賴

外部依賴的部分,代表的是耦合性。耦合性越強,代表彈性越弱,代表越容易牽一髮動全身,代表單元測試的可測試性薄弱。因此:

  1. 外部依賴越多,可測試性越低,撰寫單元測試程式的成本與時間越高。(重構解耦完才能撰寫 isolated unit test)
  2. 若單元測試成本過高,且環境允許使用整合測試,那就適合直接使用整合測試。有了整合測試保護後,接著只要時間允許,需求需要,隨時可以對程式重構進行解耦,解耦完成就代表外部依賴減少了,自然撰寫 isolated unit test 的成本就降低了。

總結

整體投資報酬比依序是:複雜度高且外部依賴低 > 複雜度高且外部依賴高 > 複雜度低且外部依賴低 > 複雜度低且外部依賴高

有個簡單的例外情況:線上出錯了的程式,優先順序最高

最後,舉幾個例子:

  1. 複雜度高、外部依賴低:很多純粹邏輯驗證的 validation 屬於這一類。例如統一編號/身份證字號的驗證、不需要太多外部依賴的商業邏輯驗證(例如毛利率要>n%, 訂單金額不可以小於0、某些長度不可以過長、編碼規則驗證等等)。這類 case 很容易出錯,但其實測試成本極低。
  2. 複雜度高、外部依賴高:business/domain layer 的物件居多。重點在於職責怎麼切分,接著才是有哪一些是值得解耦的。(完全介面導向+DI的設計,是有點 over design 但不失為一個簡單的 policy)
  3. 複雜度低、外部依賴高:如果是正常的,那大概就是一些 pattern 的中間層產物,例如 adpater、model mapping、proxy 類型的。這類即使不寫測試,造成的影響不大,原因是當其他該寫測試的都寫了,一旦 runtime 執行出錯,馬上就可以找到問題可能就在這些中介層或外部依賴。另外一類正常的,就是貧血的 Dao 物件,不帶商業邏輯,但會與外部資料來源相依,例如外部的 web service, database, file 等 persistence 資源。這類型因為往往不帶邏輯,而對需求來說,想驗證的也是 to end 的 result,所以撰寫整合測試的價值優於單元測試。
  4. 複雜度低、外部依賴低:這比較常出現在非 public/internal 的 function,就讓 public 的 test cases 去 cover 即可。如果這樣的方法也是 public 的,有時間就幫他寫測試,沒時間的話,因為他沒啥邏輯,出錯的機率低,可以等到需求異動時再來補測試案例即可。(當然,如果你是 TDD,根本就不會有這些問題)

想收到第一手公開培訓課程資訊,或想詢問企業內訓、顧問、教練、諮詢服務的,請加 Odd-e Line 帳號