Почти все мои тесты JUnit написаны со следующей подписью:
public void testSomething() throws Exception
Мое рассуждение состоит в том, что я могу сосредоточиться на том, что я тестирую, а не на обработке исключений, которую JUnit, похоже, дает мне бесплатно. Но я ничего не теряю, делая это? Это против лучшей практики? Получил бы я что-нибудь, явно поймав определенные исключения в своем тесте, а затем не сработал() на них?
В общем случае, если вы тестируете случай, когда вы не ожидаете возникновения исключения, тогда я просто позволю методу проверки выбросить исключение, как вы проиллюстрировали, так как он будет хорошо различать Неудача (они не проходят одно из ваших утверждений) и Ошибка тестовых случаев (они вызывают неожиданное исключение). JUnit TestRunners поймает выброшенное исключение независимо от того, что вам не нужно беспокоиться о том, что весь ваш тестовый пакет будет спасен, если будет выброшено исключение.
С другой стороны, если вы пишете тест, который должен инициировать исключение, вы либо хотите использовать вариант @Test(expected=IllegalArgumentException.class) аннотации JUnit 4, либо более распространенную идиому JUnit 3:
try {
target.someMethodToTest();
fail("Should have gotten an exception");
} catch (IllegalStateException ise) {
//expected, it all good
}
НЕ улавливайте и терпите неудачу - вы потеряете ценную информацию. Пусть все исключения летят прямо. Это означает, что вам нужно добавить каждое проверенное исключение, которое может быть выбрано. Однако я бы посоветовал вам не принимать ленивый выход и слепо использовать throws Exception как привычку. Это оправдывает вас от необходимости даже думать о том, как ваш API действительно ведет себя в отношении исключений.
Основное преимущество заключается в том, что вы тестируете некоторый сценарий, требующий исключения (например, обработка err-r)
В JUnit4 вы можете использовать что-то вроде: @Test (expected = ArithmeticException.class), но некоторые люди считают, что это труднее читать/показывать меньше намерений, чем явный блок try {} catch (Exception e), и если вы хотел проверить состояние (скажем, какого-нибудь макетного объекта или посмотреть, было ли исключение выбрано в нужном месте или зарегистрировано или что-то подобное)
Если генерируется исключение, и вы этого не ожидаете, тест должен завершиться неудачно.
Если это неконтролируемое исключение, я разрешаю исключение, и JUnit не выполняет проверку.
Если это проверенное исключение, у вас есть выбор: либо добавьте исключение в предложение throws подписи метода, либо поймайте его внутри метода. Компилятор заставит вас выбирать, потому что вы не можете запускать код без какого-либо из этих вариантов.
В последнее время я обычно не перехватывал исключения внутри своих тестов. Если он должен был выбросить исключение, я помечаю его как таковой аннотацией. Если он выбрасывает исключение, я оставил JUnit неудачным тестом для меня. Если это проверенное исключение, я добавляю предложение throws к сигнатуре метода и оставляю JUnit неудачным для меня тест.