測試案例壞味道（2）：Obscure Test

March 03 10:22~11:50

 

介紹完〈測試案例壞味道 （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壞味道。

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

***

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