JUnit 5: Comment faire valoir une exception est levée?

Vous pouvez utiliser assertThrows(), qui vous permet de tester plusieurs exceptions dans le même test. Avec le soutien pour les lambdas de Java 8, c'est la manière canonique de test pour les exceptions dans JUnit.

Par la JUnit docs:

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

@Test
void exceptionTesting() {
    MyException thrown =
        assertThrows(MyException.class,
           () -> myObject.doThing(),
           "Expected doThing() to throw, but it didn't");

    assertTrue(thrown.getMessage().contains("Stuff"));
}

Ils ont changé dans JUnit 5 (prévu: InvalidArgumentException, réel: méthode invoquée) et le code ressemble à ceci:

@Test
public void wrongInput() {
    Throwable exception = assertThrows(InvalidArgumentException.class,
            ()->{objectName.yourMethod("WRONG");} );
}

Vous pouvez utiliser assertThrows(). Mon exemple est tiré de la documentation http://junit.org/junit5/docs/current/user-guide/

import org.junit.jupiter.api.Test;

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

....

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

En fait, je pense qu'il y a une erreur dans la documentation pour cet exemple particulier. La méthode qui est prévu est expectThrows

public static void assertThrows(
public static <T extends Throwable> T expectThrows(

Il y a 3 moyens de faire valoir une certaine exception dans Junit. Nous allons écrire les scénarios de test unitaire pour elle.

1. try-catch idiome
Cet idiome est l'un des plus populaires car il était utilisé déjà dans JUnit 3. Cette approche est un modèle commun. Le test échoue si aucune exception n'est levée et l'exception elle-même est vérifiée dans une clause catch.

@Test
public void convertIntoUpperCase_withInvalidInput_tryCatchIdiom() {
    try {
        exceptionHandling.convertIntoUpperCase("");
        fail("It should throw IllegalArgumentException");
    } catch (IllegalArgumentException e) {
        Assertions.assertThat(e)
                .isInstanceOf(IllegalArgumentException.class)
                .hasMessage("Empty value is passed.");
    }
}

2. @Test devrait annotation
Dans cette approche, nous préciser les attendus exception dans @Test comme ci-dessous
@Test(prévu = IllegalArgumentException.class)

Lorsque l'exception n'était pas levée, vous obtiendrez le message suivant: java.lang.AssertionError: Attendu exception: java.lang.IllegalArgumentException

Avec cette approche, vous devez être prudent, cependant. Parfois, il est tentant de s'attendre à ce général Exception RuntimeException ou même un Throwable. Et cela est considéré comme une mauvaise pratique parce que votre code peut lancer une exception dans d'autres endroits que vous ne le devrait et votre test sera toujours passer!

L'un des inconvénient de cette approche est que vous ne pouvez pas affirmer pour le message d'exception.

@Test(expected = IllegalArgumentException.class)
public void convertIntoUpperCase_withInvalidInput_testExpected() {
    exceptionHandling.convertIntoUpperCase("");
}

3. Junit @Règle
Le même exemple peut être créé à l'aide de ExceptedException règle. La règle doit être un champ marqué par @Règle d'annotation.

    @Test
    public void convertIntoUpperCase_withInvalidInput_ExpectedExceptionRule() {
        exception.expect(IllegalArgumentException.class);
        exception.expectMessage("Empty value is passed.");
        exceptionHandling.convertIntoUpperCase("");
    }

- Je trouver le code ci-dessus plus lisible donc je préfère utiliser cette approche.

Lorsque l'exception n'est pas levée, vous obtiendrez le message suivant: java.lang.AssertionError: essai Prévu à jeter (une instance de java.lang.IllegalArgumentException et d'exception avec le message “valeur Vide est passé.”). Assez agréable.

Mais pas toutes les exceptions, je vérifie avec l'approche ci-dessus. Parfois, j'ai besoin de vérifier que le type de l'exception levée puis-je utiliser l'annotation @Test.