TestNG: Как проверить обязательные исключения?

Question

Я хотел бы написать тест TestNG, чтобы убедиться, что исключение выбрано под конкретным условием и не прошел тест, если исключение не выбрано. Есть ли простой способ сделать это, не создавая дополнительную логическую переменную?

Связанный блог на эту тему: http://konigsberg.blogspot.com/2007/11/testng-and-expectedexceptions-ive.html

Answer 1

@Test(expectedExceptions) полезно для наиболее распространенных случаев:

• Вы ожидаете, что конкретное исключение будет брошено
• Вам нужно сообщение этого исключения содержат определенные слова

За документации испытание не сработает, если не будет выброшено expectedException:

Список исключений, которые должен выдать тестовый метод. Если исключение или другой, кроме одного в этом списке, не будут выбрасываться, этот тест будет отмечен как сбой.

Вот несколько сценариев, в которых @Test(expectedExceptions) не является достаточным:

• Ваш метод испытаний имеет несколько заявлений, и только один из них, как ожидается, бросить
• Вы бросаете свой собственный тип исключения и вы должны убедиться, что он соответствует определенному критерию

в таких случаях, вы должны просто вернуться к традиционной (предварительно TestNG) модель:

try { 
    // your statement expected to throw 
    fail(); 
} 
catch(<the expected exception>) { 
    // pass 
} 

Answer 2

Почему вы не использовать TRY/не/образец поймать упомянутый в блоге вы связаны?

Answer 3

Я должен не соглашаться со статьей о характере применяемых методов тестирования. Решение использует затвор, чтобы проверить, будет ли тест успешным или неудачным на промежуточной стадии.

На мой взгляд, лучше использовать Guard Assertions, особенно для таких испытаний (при условии, что тест не окажется длинным и сложным, что само по себе является анти-шаблоном). Использование охранных утверждений заставляет вас спроектировать SUT одним из следующих способов:

• Разработать сам метод, чтобы предоставить достаточную информацию в результате того, прошел или не удалось выполнить вызов. Иногда это невозможно сделать, поскольку намерение дизайнера не должно возвращать результат и вместо этого вызывать исключение (это может быть рассмотрено во втором случае).
• спроектируйте SUT так, чтобы это было state can be verified после каждого значимого вызова метода.

Но прежде, чем мы рассмотрим выше возможности, посмотрите на следующий фрагмент снова:

plane.bookAllSeats(); 
plane.bookPlane(createValidItinerary(), null); 

Если намерение состоит в том, чтобы проверить bookPlane() и проверить, для выполнения этого метода, он лучше иметь bookAllSeats() в приспособлении. В моем понимании, вызов bookAllSeats() эквивалентен настройке SUT, чтобы гарантировать, что вызов функции bookPlane() не удался, и, следовательно, наличие приспособления для этого будет делать для более читаемого теста. Если намерение отличается, я бы рекомендовал тестировать состояние после каждого перехода (как я обычно делал бы в функциональных тестах), чтобы помочь определить первопричину сбоя.

Answer 4

catch-exception содержит, вероятно, все необходимое для проверки ожидаемых исключений.

Answer 5

@Test(expectedExceptions = AnyClassThatExtendsException.class, expectedExceptionsMessageRegExp = "Exception message regexp") 

Или, если вы не хотите, чтобы проверить сообщение об исключении, только ниже достаточно

@Test(expectedExceptions = AnyClassThatExtendsException.class) 

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