我應該使用帶斷言的try-catch塊

這個問題記住了很長一段時間，我想知道是否應該使用try-catch塊來聲明或不聲明？的示例 -我應該使用帶斷言的try-catch塊

1. assertEquals(actual, expected); 
2. try 
{ 
assertEquals(actual, expected); 
} 
catch(AssertionError e) 
{ 
e.printStackTrace(); 
}

有什麼好的做法？ 1或2？ TIA

來源

2016-09-27 surendra

捕捉異常有什麼好處？當然，你希望測試失敗... –

不，你當然不應該那樣做。斷言的目的是當它失敗時，它會拋出斷言錯誤，以便通知測試單元引擎。

所以，簡單地說，做斷言。並使其工作:)。如果失敗了，你應該解決問題。

另一方面，如果你想測試是否引發異常。你可以做到這一點在幾個方面：

@Test(expected = NullPointerException.class) 
public void myTestForException() { 
    callMethodThatThrowsNullPointerException(); 
}

，或者你可以使用一個try/catch：

@Test 
public void myTest() { 
    try { 
     fail("Should throw whatever"); 
    } catch (MyException e) { 
     // Everything is fine, test passed 
    } 
}

來源

2016-09-27 08:17:19

有一種更好的測試方法來拋出異常。使用JUnit ExpectedException規則。它們記錄在JUnit網站上。 –

使用JUnit或TestNG的，或者那種東西對你的測試整點是您可以在您的項目中進行數千次測試，並自動化測試。運行測試可以是構建過程的一部分，並且您可以獲得一些有關已測試多少測試的反饋。當您的項目不僅僅是一小撮班級時，這是絕對必要的。

有關捕獲assertEquals拋出並將其報告給控制檯的錯誤的想法並不好。主要是因爲它使得測試通過當斷言失敗。這意味着無論您用於運行測試（例如Jenkins）是否報告錯誤的結果。例如，您會看到5000個測試中有5000個測試通過，即使其中的很多測試都包含失敗的斷言。突然你的大套測試沒有什麼價值。

此外，您仔細打印的堆棧跟蹤將在所有各種測試的輸出大量丟失時丟失。

所以簡短的回答是，你的想法（1）是正確的做法。這是每個人都做的。這意味着您的測試結果會得到適當的報告。你不應該寫你的想法這樣的測試（2）。

來源

2016-09-27 09:26:25

我應該使用帶斷言的try-catch塊

回答

相關問題