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