JUnit中測試異常丟擲的方法

最近在做twu關於tdd的作業，對junit中測試異常丟擲的方法進行了一些學習和思考。

在進行單元測試的時候有的時候需要測試某一方法是否丟擲了正確的異常。例如，我有乙個方法，裡面對乙個list進行讀取操作，可能會丟擲indexoutofbound***ception，我希望在單元測試中通過測試保證該方法會正確的丟擲正確型別的異常。總結起來這樣的測試異常是否被正確丟擲

校驗方式有三種：

1. try…fail…catch…

@test
public
voidtestexceptionmessage()
catch
(indexoutofbound***ception anindexoutofbound***ception)
}

這種寫法看上去和實現類的寫法很相似，當沒有異常被丟擲的時候fail方法會被呼叫，輸出測試失敗的資訊。

2.@test(expected=***)

@test
(expected= indexoutofbound***ception.
class
)public
void
empty()

這種寫法看上去簡單了一些，但是它有乙個潛在的問題：當被標記的這個測試方法中的任何乙個操作丟擲了相應的異常時，這個測試就會通過。這就意味著有可能丟擲異常的地方並不是我們期望的那個操作。雖然這種情況可以在寫test case的時候人為的避免，但是還是有更好的方法來測試異常丟擲。

3.expectedexception rule

@rule
public expectedexception thrown = expectedexception.
none()
;@test
public
void
shouldtestexceptionmessage()
throws indexoutofbound***ception

這種方法除了可以指定期望丟擲的異常型別之外還可以指定在丟擲異常時希望同時給出的異常資訊。它需要在測試之前使用rule標記來指定乙個expectedexception，並在測試相應操作之前指定期望的exception型別（如indexoutofboundexception.class）

這三種方法都可以做到測試相應的操作是否丟擲了期望的異常，但是哪種方法更好更適合使用呢？

我的總結是：

try…fail…catch > expectedexception > @test(expected=***)

我之所以認為try…fail…catch方法比expectedexception好是因為：

try…fail…catch更符合一般的test function的風格，先進行某項操作，在對結果進行assert。而expectedexception的順序確實先指明期待的結果再進行相應的操作。

雖然tdd的最佳實踐是每個test function只有乙個assert，但是還是在有些情況下會在同乙個test function裡使用多個assert來對不同的方面進行測試。但是使用expectedexception進行異常測試後，當前的test function就結束了，如果在expect的相應操作之後還有assert的話會被自動跳過，而try…fail…catch則不會跳出當前test function, 其後面的assert依然會被順序執行。

expectedexception是junit提供的，因此在使用別的測試框架時這樣的測試方法無效。而try/catch有更多的測試框架支援(fail也是junit提供的。使用別的測試框架的時候不能使用fail來給出測試失敗的資訊)

-----以下是我自己的看法：

try…fail…catch 這種寫法，比較容易忽略catch前面的fail()，且不容易檢查，

一般我們看到try…catch會認為是對丟擲的異常做處理，但在這裡是在驗證，閱讀**時不流暢，且容易讓其他人有誤解

個人比較喜歡expectedexception的方式

但是在實際使用過程中，如果需要有其他的斷言或者mock的verify的判斷，使用 try…fail…catch的寫法可以比較好的覆蓋，否則後面的斷言和verify就無法執行了。

JUnit中測試異常丟擲的方法

JUnit三（異常測試）

junit中對異常測試的小結總結

JUnit編寫異常測試的Testcase

JUnit中測試異常丟擲的方法

JUnit三（異常測試）

junit中對異常測試的小結總結

JUnit編寫異常測試的Testcase

相關推薦