單元測試時期望值是丟擲異常的情況

最近在做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）

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

@test(expected=***) > 根本不測異常是否正確丟擲

expectedexception > @test(expected=***)

try…fail…catch > expectedexception

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

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

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

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

單元測試時期望值是丟擲異常的情況

MAX值單元測試

什麼是單元測試

js單元測試，使用斷言捕獲丟擲的異常

單元測試時期望值是丟擲異常的情況

MAX值 單元測試

什麼是單元測試

js單元測試，使用斷言捕獲丟擲的異常

相關推薦

MAX值單元測試