Как я могу подтвердить свое сообщение об исключении с помощью аннотации JUnit Test?


315

Я написал несколько тестов JUnit с @Testаннотацией. Если мой метод теста выдает проверенное исключение и если я хочу подтвердить сообщение вместе с исключением, есть ли способ сделать это с помощью JUnit@Test аннотации ? AFAIK, JUnit 4.7 не предоставляет эту функцию, но есть ли в будущих версиях ее? Я знаю, что в .NET вы можете утверждать сообщение и класс исключений. Ищете похожую функцию в мире Java.

Это то, что я хочу:

@Test (expected = RuntimeException.class, message = "Employee ID is null")
public void shouldThrowRuntimeExceptionWhenEmployeeIDisNull() {}

1
Теперь, когда я думаю об этом немного больше ... Вы уверены, что это хорошая идея, чтобы утвердить сообщение? Ваш вопрос заставил меня немного покопаться в исходном коде junit, и кажется, что они могли бы легко добавить эту функцию. Тот факт, что они этого не сделали , заставляет меня думать, что это не может считаться хорошей практикой. Почему в вашем проекте важно утверждать сообщение?
c_maker

10
Хороший вопрос. Скажите, что метод, содержащий 15 строк кода, выдает одно и то же исключение из 2 разных мест. Мои тестовые случаи должны утверждать не только класс исключения, но и сообщение в нем. В идеальном мире любое ненормальное поведение должно иметь свое собственное исключение. Если бы это было так, мой вопрос никогда бы не возник, но у производственных приложений нет уникального пользовательского исключения для каждого ненормального поведения.
Cshah

В качестве примечания - @expectedExceptionMessageв PHPUnit есть аннотация.
Bancer

Ответы:


535

Вы можете использовать @Ruleаннотацию ExpectedException, например:

@Rule
public ExpectedException expectedEx = ExpectedException.none();

@Test
public void shouldThrowRuntimeExceptionWhenEmployeeIDisNull() throws Exception {
    expectedEx.expect(RuntimeException.class);
    expectedEx.expectMessage("Employee ID is null");

    // do something that should throw the exception...
    System.out.println("=======Starting Exception process=======");
    throw new NullPointerException("Employee ID is null");
}

Обратите внимание, что пример в ExpectedExceptionдокументации (в настоящее время) неверен - здесь нет открытого конструктора, поэтому вы должны его использовать ExpectedException.none().


1
Примечание: для меня, когда expectMessageбыла указана пустая строка, сравнение для сообщения не проводилось
redDevil

1
Полезно для меня. Спасибо. Метод test должен иметь throws RuntimeExceptionпосле добавления код, который выдает исключение. Не лови это ...
Бумбольт

5
Я лично не хотел бы использовать это, так как создание полей с целью небольшого подмножества методов - плохая практика. Не критика ответа, а дизайна JUnit. Гипотетическое решение ОП было бы намного лучше, если бы оно существовало.
Шридхар Сарнобат

2
@redDevil: Ожидаемое сообщение проверяет, содержит ли сообщение об ошибке строку, указанную в этой функции (например, подстроку сообщения об ошибке)
tuan.dinh

3
Ожидаемое сообщение со строковым параметром выполняет проверку String.contains, для точного совпадения сообщения об исключении используйте совпадение Hamcrestfailure.expectMessage(CoreMatchers.equalTo(...))
Sivabalan

42

Мне нравится @Ruleответ. Однако, если по какой-то причине вы не хотите использовать правила. Есть третий вариант.

@Test (expected = RuntimeException.class)
public void myTestMethod()
{
   try
   {
      //Run exception throwing operation here
   }
   catch(RuntimeException re)
   {
      String message = "Employee ID is null";
      assertEquals(message, re.getMessage());
      throw re;
    }
    fail("Employee Id Null exception did not throw!");
  }

32

Вы должны использовать @Test(expected=SomeException.class)? Когда мы должны утверждать фактическое сообщение об исключении, это то, что мы делаем.

@Test
public void myTestMethod()
{
  try
  {
    final Integer employeeId = null;
    new Employee(employeeId);
    fail("Should have thrown SomeException but did not!");
  }
  catch( final SomeException e )
  {
    final String msg = "Employee ID is null";
    assertEquals(msg, e.getMessage());
  }
}

6
Я знаю о написании блока catch и использовании assert в нем, но для лучшей читаемости кода я хочу делать с аннотациями.
Cshah

Также вы не получите такого приятного сообщения, как при правильном подходе.
НеплатныйУдай

15
Проблема с версией попробовать / поймать, теперь, JUnit обеспечивает @Test(expected=...)и ExpectedExceptionявляется то , что я видел много раз кто - то забывчивость поставить вызов fail()на конце tryблока . Если проверка кода не обнаружена, ваш тест может быть ложно-положительным и всегда проходить успешно.
Уильям Прайс

Вот почему мне не нравятся все эти декларативные вещи. Это затрудняет доступ к тому, что вы хотите.
Шридхар Сарнобат

30

В JUnit 4.13 вы можете сделать:

import static org.junit.Assert.assertEquals;
import static org.junit.Assert.assertThrows;

...

@Test
void exceptionTesting() {
  IllegalArgumentException exception = assertThrows(
    IllegalArgumentException.class, 
    () -> { throw new IllegalArgumentException("a message"); }
  );

  assertEquals("a message", exception.getMessage());
}

Это также работает в JUnit 5, но с другим импортом:

import static org.junit.jupiter.api.Assertions.assertEquals;
import static org.junit.jupiter.api.Assertions.assertThrows;

...

Понравилось это решение. Если перейти к JUnit 5.
WesternGun

Gaaaaaaaaa. 4.13 все еще в бета-версии на сегодня (осень, 2019)? mvnrepository.com/artifact/junit/junit
granadaCoder

v4.13 больше не находится в бета-версии (выпуск в январе 2020 г.)
Simon

11

На самом деле, лучше всего использовать try / catch. Зачем? Потому что вы можете контролировать место, где вы ожидаете исключения.

Рассмотрим этот пример:

@Test (expected = RuntimeException.class)
public void someTest() {
   // test preparation
   // actual test
}

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

Вот почему гораздо лучше использовать try / catch, чем полагаться на аннотацию.


К сожалению, это мой ответ тоже.
Шридхар Сарнобат

2
Беспокойство относительно изменений кода облегчается наличием небольших, специфичных для перестановки тестовых случаев. Иногда это неизбежно, и мы должны полагаться на метод catch / try, но если это происходит часто, то есть вероятность, что нам нужно пересмотреть способ написания функций нашего тестового примера.
luis.espinal

Это проблема с вашим тестом и / или кодом. Вы НЕ ожидаете общего исключения RuntimeException, ожидаете конкретного исключения или, по крайней мере, конкретного сообщения.
DennisK

Я использовал RuntimeExceptionв качестве примера, заменить это исключение на любое другое исключение.
Кшиштоф Сисло

8

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

Добавьте этот служебный класс:

import org.junit.Assert;

public abstract class ExpectedRuntimeExceptionAsserter {

    private String expectedExceptionMessage;

    public ExpectedRuntimeExceptionAsserter(String expectedExceptionMessage) {
        this.expectedExceptionMessage = expectedExceptionMessage;
    }

    public final void run(){
        try{
            expectException();
            Assert.fail(String.format("Expected a RuntimeException '%s'", expectedExceptionMessage));
        } catch (RuntimeException e){
            Assert.assertEquals("RuntimeException caught, but unexpected message", expectedExceptionMessage, e.getMessage());
        }
    }

    protected abstract void expectException();

}

Затем для моего модульного теста мне нужен только этот код:

@Test
public void verifyAnonymousUserCantAccessPrivilegedResourceTest(){
    new ExpectedRuntimeExceptionAsserter("anonymous user can't access privileged resource"){
        @Override
        protected void expectException() {
            throw new RuntimeException("anonymous user can't access privileged resource");
        }
    }.run(); //passes test; expected exception is caught, and this @Test returns normally as "Passed"
}

2

При использовании @Rule набор исключений применяется ко всем методам тестирования в классе Test.


2
Используя ответ Джесси Мерримана, исключение проверяется только в тестовых методах, которые вызывают функциюExexExexex () и ExExexMessage (). Другие методы будут использовать определение Ожидаемое исключение ExExExEx.None (), то есть исключение не ожидается.
Egl

2

Мне никогда не нравился способ утверждать исключения с Junit. Если я использую «ожидаемый» в аннотации, кажется, с моей точки зрения, мы нарушаем шаблон «дано, когда, тогда», потому что «тогда» помещается вверху определения теста.

Также, если мы используем «@Rule», нам приходится иметь дело с таким большим количеством стандартного кода. Итак, если вы можете установить новые библиотеки для своих тестов, я бы посоветовал взглянуть на AssertJ (эта библиотека теперь поставляется с SpringBoot)

Затем тест, который не нарушает принципы «дано / когда / тогда» и выполняется с помощью AssertJ для проверки:

1 - Исключением является то, что мы ожидаем. 2 - также есть ожидаемое сообщение

Будет выглядеть так:

 @Test
void should_throwIllegalUse_when_idNotGiven() {

    //when
    final Throwable raisedException = catchThrowable(() -> getUserDAO.byId(null));

    //then
    assertThat(raisedException).isInstanceOf(IllegalArgumentException.class)
            .hasMessageContaining("Id to fetch is mandatory");
}

1

Мне нравится ответ user64141, но я нашел, что он может быть более обобщенным. Вот мой дубль:

public abstract class ExpectedThrowableAsserter implements Runnable {

    private final Class<? extends Throwable> throwableClass;
    private final String expectedExceptionMessage;

    protected ExpectedThrowableAsserter(Class<? extends Throwable> throwableClass, String expectedExceptionMessage) {
        this.throwableClass = throwableClass;
        this.expectedExceptionMessage = expectedExceptionMessage;
    }

    public final void run() {
        try {
            expectException();
        } catch (Throwable e) {
            assertTrue(String.format("Caught unexpected %s", e.getClass().getSimpleName()), throwableClass.isInstance(e));
            assertEquals(String.format("%s caught, but unexpected message", throwableClass.getSimpleName()), expectedExceptionMessage, e.getMessage());
            return;
        }
        fail(String.format("Expected %s, but no exception was thrown.", throwableClass.getSimpleName()));
    }

    protected abstract void expectException();

}

Обратите внимание, что оставление оператора «fail» в блоке try приводит к перехвату связанного исключения утверждения; использование возврата в операторе catch предотвращает это.


0

Импортируйте библиотеку catch-exception и используйте ее. Это намного чище, чем ExpectedExceptionправило или try-catch.

Пример формы их документов:

import static com.googlecode.catchexception.CatchException.*;
import static com.googlecode.catchexception.apis.CatchExceptionHamcrestMatchers.*;

// given: an empty list
List myList = new ArrayList();

// when: we try to get the first element of the list
catchException(myList).get(1);

// then: we expect an IndexOutOfBoundsException with message "Index: 1, Size: 0"
assertThat(caughtException(),
  allOf(
    instanceOf(IndexOutOfBoundsException.class),
    hasMessage("Index: 1, Size: 0"),
    hasNoCause()
  )
);

-2
@Test (expectedExceptions = ValidationException.class, expectedExceptionsMessageRegExp = "This is not allowed")
public void testInvalidValidation() throws Exception{
     //test code
}

Может кто-нибудь помочь мне понять, почему этот ответ -1
ааша

Вопрос спрашивает, Junitно TestNG
ваш
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.