¿Cómo hago valer mi mensaje de excepción con la anotación JUnit Test?

He escrito algunas pruebas JUnit con @Testanotaciones. Si mi método de prueba arroja una excepción marcada y si quiero afirmar el mensaje junto con la excepción, ¿hay alguna manera de hacerlo con la @Testanotación JUnit ? AFAIK, JUnit 4.7 no proporciona esta función, pero ¿alguna versión futura la proporciona? Sé que en .NET puedes afirmar el mensaje y la clase de excepción. Buscando una característica similar en el mundo de Java.

Esto es lo que quiero:

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

Podrías usar la @Ruleanotación con ExpectedException, así:

@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");
}

Tenga en cuenta que el ejemplo en los ExpectedExceptiondocumentos es (actualmente) incorrecto: no hay un constructor público, por lo que debe usarlo ExpectedException.none().

Me gusta la @Rulerespuesta Sin embargo, si por alguna razón no quieres usar reglas. Hay una tercera opción.

@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!");
  }

¿Tienes que usar @Test(expected=SomeException.class)? Cuando tenemos que afirmar el mensaje real de la excepción, esto es lo que hacemos.

@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());
  }
}

En JUnit 4.13 puedes hacer:

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());
}

Esto también funciona en JUnit 5 pero con diferentes importaciones:

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

...

En realidad, el mejor uso es con try / catch. ¿Por qué? Porque puedes controlar el lugar donde esperas la excepción.

Considere este ejemplo:

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

¿Qué pasa si un día se modifica el código y la preparación de la prueba arrojará una RuntimeException? En ese caso, la prueba real ni siquiera se prueba e incluso si no arroja ninguna excepción, la prueba pasará.

Es por eso que es mucho mejor usar try / catch que confiar en la anotación.

Raystorm tuvo una buena respuesta. Tampoco soy un gran admirador de las reglas. Hago algo similar, excepto que creo la siguiente clase de utilidad para ayudar a la legibilidad y usabilidad, que es una de las grandes ventajas de las anotaciones en primer lugar.

Agregue esta clase de utilidad:

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();

}

Luego, para mi prueba unitaria, todo lo que necesito es este código:

@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"
}

Si usa @Rule, el conjunto de excepciones se aplica a todos los métodos de prueba en la clase Prueba.

Nunca me gustó la forma de afirmar excepciones con Junit. Si uso el "esperado" en la anotación, parece que desde mi punto de vista estamos violando el patrón "dado, cuándo, entonces" porque el "entonces" se coloca en la parte superior de la definición de la prueba.

Además, si usamos "@Rule", tenemos que lidiar con tanto código repetitivo. Entonces, si puede instalar nuevas bibliotecas para sus pruebas, le sugiero que eche un vistazo a AssertJ (esa biblioteca ahora viene con SpringBoot)

Luego, una prueba que no está violando los principios "dado / cuándo / entonces", y se realiza utilizando AssertJ para verificar:

1 - La excepción es lo que esperamos. 2 - También tiene un mensaje esperado

Se verá así:

 @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");
}

Me gusta la respuesta de user64141 pero descubrí que podría ser más generalizada. Aquí está mi opinión:

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();

}

Tenga en cuenta que si deja la instrucción "fail" dentro del bloque try, se detecta la excepción de aserción relacionada; El uso de return dentro de la instrucción catch evita esto.

Importe la biblioteca de excepción de captura y úsela. Es mucho más limpio que la ExpectedExceptionregla o a try-catch.

Ejemplo de sus documentos:

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()
  )
);

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