l

2015年3月5日 星期四

測試案例壞味道(3):Conditional Test Logic

March 03 16:14~17:20

螢幕截圖 2015-03-03 17.23.09

 

條件邏輯(包含if-else、while、for等)在撰寫程式的時候是很好用的工具,但用不好卻會變成人人喊打的對像。撰寫自動化測試案例的目的之一是為了驗證待測程式的行為。如果測試案例本身的行為過於複雜,那麼誰要來驗證測試案例的行為?Conditional Test Logic壞味道是造成複雜測試案例的原因之一,如果可以儘量簡化測試案例的邏輯,簡單到根本不需要測試,那就太好了。

***

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

  • Flexible Test:測試案例包含了條件邏輯,依據不同的執行環境驗證不同的功能。例如,。

if (isWindows ())

     assertEquals(ExpectedOnWin, ActualResult);

else if (isLinux())

      assertEquals(ExpectedOnLinux, ActualResult);

  • Production Logic in Test:有時候為了得到expected result,會把計算expected result的程式邏輯寫在測試案例中(這個邏輯就是production code的邏輯),這時候就有可能因為計算expected result的程式邏輯本身含有條件判斷式,而使得測試案例具備Conditional Test Logic壞味道。
  • Complex Teardown:複雜的teardown程式也會導致Conditional Test Logic壞味道。更慘的是,這一的teardown程式很容易一不小心就沒有把測試環境清理乾淨,造成時好時壞的測試案例(請參考〈對付時好時壞的測試案例(2):Lack of Isolation〉)。
  • Multiple Test Conditions:用相同的測試邏輯來測試一組輸入資料,每一組資料都有相對應的expected result。在這種情況下,通常會使用for loop來驗證這組資料,因而產生Conditional Test Logic壞味道。

在JUnit 4之前,這種情況很難避免。JUnit 4之後支援parameterized test(參數化測試案例,請參考〈JUnit4的參數化測試案例(上)〉與〈JUnit4的參數化測試案例(下)〉),可以用來避免這個壞味道。

***

再強調一次,測試案例越簡單越好,最好簡單到不用測試也可以確定它的正確性。

***

友藏內心獨白:乞丐中的霸主,還是乞丐。

沒有留言:

張貼留言