l

2015年3月4日 星期三

測試案例壞味道(2):Obscure Test

March 03 10:22~11:50

螢幕截圖 2015-03-03 12.14.53

 

介紹完〈測試案例壞味道 (1):三種分類〉,接著逐一介紹每個壞味道。今天要談的是Obscure Test(難懂的測試)。顧名思義,這種測試案例不容易一下子就看懂,以至於測試案例本身不易修改維護。當production code修改的時候,經常需要連動修改測試案例。具有Obscure Test壞味道的測試案例將使得修改的成本變高,最終可能導致測試案例被遺棄或是被註解掉,只為了不想看到xUnit測試工具所顯示的該死的紅燈挑眉質疑

Obscure Test的另一個問題是可能會導致測試案例本身產生bug,讓開發人員搞不清楚到底是production code有問題還是測試案例有問題,徒然浪費時間。另外,Obscure Test本身可能包含很多assertion。只要其中任何一個assertion發生錯誤,整個測試案例就會失敗。在這種情況之下,開發人員可能需要花費一段時間檢查,才可以得知確切的錯誤發生原因。

***

導致Obscure Test的根本原因就是沒有維持乾淨的測試案例。除了production code以外,測試案例(test code)也需要達到clean code的標準。當測試案例出現Obscure Test壞味道的時候,也就是需要重構(refactor)測試案例的時機。

xUnit Test Patterns: Refactoring Test Code》書中提到幾種導致Obscure Test壞味道的具體情況:

  • Eager Test:在單一測試方法(test method)驗證太多東西。
  • Mystery Guest:閱讀測試案例的人看不出來fixture(測試環境)和驗證邏輯之間的因果關係,因為有些fixture是在test method外部所設定的。
  • General Fixture:測試案例建立或是參考一個很大的fixture,但它只用到該fixture其中的一小部份。
  • Irrelevant Information:測試案例揭露過多fixture的細節,讓人無法專注於真正影響待測程式的行為。
  • Hard-Coded Test Data:在fixture與assertion中,或是要傳給待測程式參數的資料,被寫死在test method裡面,使得閱讀測試案例的人看不出輸入值和期待值(expected result)之間的因果關係。
  • Indirect Testing:測試案例透過間接的方式來呼叫待測程式,讓兩者的互動關係變的複雜。

***

以上這六點還蠻容易理解的,只要有寫過自動化測試的鄉民,相信都可以體會箇中滋味。在這裡Teddy要特別談Indirect Testing。有過用Mock Object技術撰寫測試案例的鄉民們,不知道有沒有感覺,Mock Object就是一種Indirect Testing?雖然Mock Object技術可以讓鄉民們隔離待測程式與外部程式,但付出的代價很可能是因為Indirect Testing(透過Mock Object技術呼叫待測程式)導致Obscure Test壞味道。

俗話說:「藥物都有毒性」,可能就是這個道理吧。

***

友藏內心獨白:這個壞味道真的很常見。

沒有留言:

張貼留言