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

Ответ 1

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

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

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

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

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

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

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

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

Ответ 2

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

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

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

@Test(expectedExceptions = AnyClassThatExtendsException.class)

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

Ответ 3

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

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

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

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

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

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

Ответ 4

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

Ответ 5

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

Ответ 6

если вы используете 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());