[JAVA] Le test de paramétrage JUnit 5 est super pratique

En parlant de JUnit 5, il fut un temps où je pensais que le test @ Nested était le meilleur choix, mais quand j'ai commencé à utiliser @ ParameterizedTest, je m'y suis tellement habitué que je me suis dit" Qu'est-ce que c'était dans JUnit 4? " se sentir bien. Cela seul peut recommander la migration.

Environnement de confirmation

JUnit 5.3
AdoptOpenJDK 11.0.3+7
macOS 10.14.3

ValueSource

Les paramètres sont spécifiés à l'aide de l'annotation «@ ValueSource». En fonction du type de paramètre, il existe des propriétés ʻints, strings, doubles`, etc.

@ParameterizedTest
@ValueSource(ints = {1, 2, 100})
void positiveNumber(int n) {
    assertTrue(isPositiveNumber(n));
}

@ParameterizedTest
@ValueSource(strings = {"Java", "java", "JAVA"})
void upperCase(String s) {
    assertEquals("JAVA", s.toUpperCase());
}

Lorsqu'ils sont exécutés dans l'EDI, les résultats des tests pour chaque paramètre sont renvoyés d'une manière facile à comprendre. Avec IntelliJ IDEA, vous pouvez même réexécuter le test pour certains paramètres.

Conversion de type implicite

Les paramètres qui peuvent être spécifiés avec @ ValueSource sont limités aux systèmes primitifs, mais la conversion de type implicite à partir de String est prise en charge pour les autres types couramment utilisés. C'est incroyablement utile si vous voulez écrire un test de date.

@ParameterizedTest
@ValueSource(strings = {"2016-01-01", "2020-01-01", "2020-12-31"})
void leapYear(LocalDate date) {
    assertTrue(date.isLeapYear());
}

Pour plus d'informations sur les conversions de type prises en charge, consultez la documentation officielle (https://junit.org/junit5/docs/5.3.0/user-guide/#writing-tests-parameterized-tests-argument-conversion-implicit) prière de se référer à.

MethodSource

Alors que @ ValueSource ne peut donner qu'un seul paramètre à la fois, l'utilisation de @ MethodSource vous permet de:

Donnez deux ou plusieurs paramètres
Donner des paramètres de type uniques
Donner des paramètres générés dynamiquement

En donnant la valeur attendue en tant que paramètre, vous pouvez facilement écrire Table Driven Test comme recommandé par le langage Go. Ceci est particulièrement utile si vous souhaitez écrire des tests pour des méthodes utilitaires qui renvoient simplement une chaîne ou un booléen.

@ParameterizedTest
@MethodSource("japaneseDateProvider")
void japaneseEra(JapaneseDate date, String expected) {
    DateTimeFormatter formatter = DateTimeFormatter.ofPattern("G").withLocale(Locale.JAPAN);
    assertEquals(expected, formatter.format(date));
}

static Stream<Arguments> japaneseDateProvider() {
    return Stream.of(
        arguments(JapaneseDate.of(1989, 1, 7), "Showa"),
        arguments(JapaneseDate.of(1989, 1, 8), "Heisei"),
        arguments(JapaneseDate.of(2019, 4, 30), "Heisei"),
        arguments(JapaneseDate.of(2019, 5, 1), "Reiwa")
    );
}

CsvSource

@ MethodSource doit définir différentes méthodes une par une, et il y a un peu de bruit autre que les données de test. Si vous n'avez pas besoin de votre propre type, vous pouvez utiliser @ CsvSource pour résoudre ce problème.

Chaque champ séparé par une virgule est un paramètre. Le mécanisme de conversion de type implicite décrit précédemment mappe automatiquement les chaînes aux types d'arguments de méthode.

@ParameterizedTest
@CsvSource({
    "1989-01-07,Showa",
    "1989-01-08,Heisei",
    "2019-04-30,Heisei",
    "2019-05-01,Reiwa"
})
void japaneseEra(LocalDate date, String expected) {
    JapaneseDate d = JapaneseDate.from(date);
    DateTimeFormatter formatter = DateTimeFormatter.ofPattern("G").withLocale(Locale.JAPAN);
    assertEquals(expected, formatter.format(d));
}

Comme enum est également soumis à une conversion de type implicite, vous pouvez écrire du code comme celui-ci: C'est facile et très pratique, mais je pense qu'il est facile d'oublier de modifier la portée de l'influence lors de la refactorisation du nom du nom de la constante enum. Je ne peux rien dire car je n'ai pas encore été sur cette scène.

@ParameterizedTest
@CsvSource({
    "JANUARY, false, 31",
    "FEBRUARY, false, 28",
    "FEBRUARY, true, 29"
})
void daysOfMonth(Month month, boolean leapYear, int expected) {
    assertEquals(expected, month.length(leapYear));
}

Si vous souhaitez inclure une chaîne de caractères vide, placez-la entre guillemets simples comme «" 2, '', true ". Par contre, si vous faites "" 2 ,, true " sans guillemets simples, ce sera nul, alors soyez prudent.

Résumé

Nous avons brièvement présenté les tests paramétrés qui ont été réorganisés dans JUnit 5. Le test de paramétrage de JUnit 4 était difficile à comprendre, et il y avait de nombreuses scènes où j'ai écrit une boucle pour l'éviter, mais je le recommande car il est très intuitif à utiliser dans JUnit 5.

Les références

JUnit 5 User Guide: 3.14. Parameterized Tests