Nieoczekiwany wyjątek jest niepowodzeniem testu, więc użytkownik nie musi ani nie chce go przechwycić.
@Test
public void canConvertStringsToDecimals() {
String str = "1.234";
Assert.assertEquals(1.234, service.convert(str), 1.0e-4);
}
Do service
nie rzucać IllegalArgumentException
ponieważ str
ma punkt dziesiętny w nim, że będzie proste niepowodzenie testu.
Oczekiwany wyjątek powinien być obsługiwany przez opcjonalny argument expected
z @Test
.
@Test(expected=NullPointerException.class)
public void cannotConvertNulls() {
service.convert(null);
}
Jeśli programista był leniwy i rzucił Exception
, lub gdyby miał service
zwrot 0.0
, test zakończy się niepowodzeniem. Tylko NPE
zakończy się pomyślnie. Należy zauważyć, że podklasy oczekiwanego wyjątku również działają. To rzadkość w przypadku NPE
s, ale jest wspólne z IOException
s oraz SQLException
s.
W rzadkich przypadkach, w których chcesz przetestować pod kątem określonego komunikatu wyjątku, użyjesz nowego, ExpectedException
JUnit @Rule
.
@Rule
public ExpectedException thrown= ExpectedException.none();
@Test
public void messageIncludesErrantTemperature() {
thrown.expect(IllegalArgumentException.class);
thrown.expectMessage("-400"); // Tests that the message contains -400.
temperatureGauge.setTemperature(-400);
}
Teraz chyba setTemperature zgłasza IAE
i wiadomość zawiera temperaturę użytkownik starał się ustawić, test nie powiedzie się. Z tej reguły można korzystać w bardziej wyrafinowany sposób.
Twój przykład można najlepiej obsługiwane przez:
private void testNumber(String word, int number)
throws OutOfRangeNumberException {
assertEquals(word, service.convert(number));
}
@Test
public final void testZero()
throws OutOfRangeNumberException {
testNumber("zero", 0);
}
Można inline testNumber
; teraz to niewiele pomaga. Możesz to zmienić w sparametryzowaną klasę testową.
ExpectedException jest preferowanym sposobem sprawdzenia dla przewidywanych wyjątków. –
Zgadzam się, a ja już przegłosowałem odpowiedź Erica. – javadeveloper
Potrzebujesz tylko ExpectedException, jeśli chcesz sprawdzić strukturę wyjątku. Na przykład, CmisExceptions powinny mieć określony powód niepowodzenia ustawiony w nich. Musiałem napisać testy, żeby to sprawdzić, i użyłem w tym celu mataczy Hamcrest. Jeśli spodziewasz się wyjątku, użyj argumentu @Test. –