測試案例壞味道（3）：Conditional Test Logic

March 03 16:14~17:20

 

條件邏輯（包含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的參數化測試案例（下）〉），可以用來避免這個壞味道。

***

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

***

友藏內心獨白：乞丐中的霸主，還是乞丐。