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

Question

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

Соответствующее сообщение в блоге на эту тему: http://konigsberg.blogspot.com/2007/11/testng-and-expectedexceptions-ive.html

Answer 1

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

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

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

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

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

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

В таких случаях вам следует просто вернуться к традиционному (pre-TestNG) шаблону:

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

Answer 2

Используйте аннотацию @Test для проверки ожидаемых исключений.

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

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

@Test(expectedExceptions = AnyClassThatExtendsException.class)

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

Answer 3

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

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

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

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

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

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

Answer 4

если вы используете Java 7 и testng, это может быть использовано для Java 8, вы также можете использовать лямбда-выражения

class A implements ThrowingRunnable{


            @Override
            public void run() throws AuthenticationFailedException{
                spy.processAuthenticationResponse(mockRequest, mockResponse, authenticationContext);
            }
        }
        assertThrows(AuthenticationFailedException.class,new A());

Answer 5

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

Answer 6

Почему бы вам не воспользоваться шаблоном try / fail / catch, упомянутым в сообщении в блоге, на которое вы ссылались?