Тестирование необязательного исключения в параметризованном тесте JUnit 4+

Я пытаюсь написать модульный тест для метода, который принимает строку в качестве параметра и выдает исключение, если оно неправильно сформировано (И NONE, если все в порядке). Я хочу написать параметризованный тест, который передает несколько строк и ожидаемое исключение (ВКЛЮЧАЯ случай, когда ни одно из них не выдается, если входная строка правильно сформирована!). При попытке использовать аннотацию @Test(expect=SomeException.class) я столкнулся с двумя проблемами:

  1. ожидание = ноль не допускается. Итак, как я могу проверить ожидаемый результат исключения NO (для правильно сформированных входных строк)?

  2. ожидать = невозможно? Я еще не пробовал, но я сильно подозреваю, что это так после прочтения этого (не могли бы вы указать, правда ли это?): http://tech.groups.yahoo.com/group/junit/message/19383 Тогда это кажется лучшим решением, которое я нашел. Что вы думаете об этом, особенно по сравнению с этим: Как Я тестирую исключения в параметризованном тесте?

Заранее спасибо за любую помощь, жду обсуждения :)


person juniper    schedule 01.09.2011    source источник


Ответы (3)


Создайте два класса тестовых случаев:

  • Валидстрингстест
  • Инвалидстрингстест

Очевидно, что первый проверяет все виды допустимых входных данных (не генерируя исключение), в то время как второй всегда ожидает исключение.

Помните: удобочитаемость ваших тестов даже важнее, чем удобочитаемость производственного кода. Не используйте дурацкие флаги, условия и логику в тестах JUnit. Простота — король.

Также см. мой ответ здесь за подсказку, как правильно проверять исключения.

person Tomasz Nurkiewicz    schedule 01.09.2011

Имейте два разных теста - один для действительных входных данных и один для недопустимых. Я не использовал JUnit 4, поэтому не могу комментировать точный формат аннотации, но в основном у вас будет один параметризованный тест с различными недопустимыми входными данными, в котором говорится, что он действительно ожидает исключения, и отдельный тест с различными действительными входными данными, который ничего не говорит об исключениях. Если в вашем тесте не сказано, что это должно быть выброшено исключение, тест завершится ошибкой.

person Jon Skeet    schedule 01.09.2011

Разделение тестовых случаев на два тестовых класса является подходящим подходом во многих случаях, как уже отмечали Томаш и Джон.

Но есть и другие случаи, когда это разделение не является хорошим выбором только с точки зрения удобочитаемости. Предположим, что строки в протестированном наборе данных имеют естественный порядок, и если строки отсортированы в этом естественном порядке, может быть легко увидеть, охватывают ли тестовые данные все соответствующие варианты использования. Если разделить тестовые наборы на два тестовых класса, уже не будет простого способа увидеть, все ли релевантные тестовые наборы покрыты. В этих случаях Как проверить исключения в параметризованном тесте? кажется действительно лучшим решением.

person rwitzel    schedule 25.06.2012