[JAVA]

Meiner persönlichen Meinung nach kann die Codeüberprüfung sowohl eine Lernsitzung als auch eine Qualitätsverbesserung sein. Ich bekomme Vorschläge und Ratschläge von anderen Programmierern für den Code, den ich geschrieben habe, und diskutiere ihn manchmal. Eine solche Gelegenheit ist mit Ausnahme von Codeüberprüfungen unwahrscheinlich. Es ist zu verschwenderisch, nur auf einen Fehler hinzuweisen. Java, fehlerhafte Farbfelder, Codeüberprüfungen, Unterstützung für neue Programmierer Der parametrisierte JUnit 5-Test ist sehr praktisch. JUnit 5 galt einst als "@ Nested" -Test, aber ich begann mit der Verwendung von "@ ParameterizedTest" Es fühlt sich so gut an, sich daran zu gewöhnen, dass ich denken kann: "Was war das in JUnit 4?" Dies allein kann eine Migration empfehlen. Bestätigungsumgebung

ValueSource

Parameter werden mit der Annotation @ ValueSource angegeben. Abhängig von der Art des Parameters gibt es die Eigenschaften "Ints", "Strings" und "Doubles".

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

Bei der Ausführung in der IDE werden die Testergebnisse für jeden Parameter auf leicht verständliche Weise zurückgemeldet. Mit IntelliJ IDEA können Sie den Test für bestimmte Parameter sogar erneut ausführen.

image.png

Implizite Typkonvertierung

Die Parameter, die mit @ ValueSource angegeben werden können, sind auf primitive Systeme beschränkt, aber die implizite Typkonvertierung von String wird für andere häufig verwendete Typen unterstützt. Dies ist wahnsinnig nützlich, wenn Sie einen Datumstest schreiben möchten.

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

Weitere Informationen zu unterstützten Typkonvertierungen finden Sie in der offiziellen Dokumentation (https://junit.org/junit5/docs/5.3.0/user-guide/#writing-tests-parameterized-tests-argument-conversion-implicit). bitte beziehen Sie sich auf.

MethodSource

Während "@ ValueSource" jeweils nur einen Parameter angeben kann, können Sie mit "@ MethodSource":

Indem Sie den erwarteten Wert als Parameter angeben, können Sie einfach Table Driven Test schreiben, wie von der Sprache Go empfohlen. Dies ist besonders nützlich, wenn Sie Tests für Dienstprogrammmethoden schreiben möchten, die nur einen String oder einen Booleschen Wert zurückgeben.

@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 muss nacheinander verschiedene Methoden definieren, und es gibt ein kleines Rauschen außer den Testdaten. Wenn Sie keinen eigenen Typ benötigen, können Sie dieses Problem mit "@ CsvSource" beheben.

Jedes durch Komma getrennte Feld ist ein Parameter. Der zuvor beschriebene Mechanismus der impliziten Typkonvertierung (#Implicit Type Conversion) ordnet Strings automatisch Methodenargumenttypen zu.

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

Da enum auch einer impliziten Typkonvertierung unterliegt, können Sie Code wie folgt schreiben: Es ist einfach und sehr praktisch, aber ich denke, es ist leicht zu vergessen, den Einflussbereich zu ändern, wenn der Name des Enum-Konstantennamens umgestaltet wird. Ich kann nichts sagen, weil ich noch nicht in dieser Szene war.

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

Wenn Sie eine leere Zeichenfolge einfügen möchten, setzen Sie sie in einfache Anführungszeichen wie "2,", "true". Im Gegenteil, wenn Sie "2 ,, true" "ohne einfache Anführungszeichen ausführen, ist dies null. Seien Sie also vorsichtig.

Zusammenfassung

Wir haben kurz die parametrisierten Tests vorgestellt, die in JUnit 5 überarbeitet wurden. Der Parametrisierungstest von JUnit 4 war schwer zu verstehen, und es gab viele Szenen, in denen ich eine Schleife geschrieben habe, um dies zu vermeiden. Ich empfehle dies jedoch, da die Verwendung in JUnit 5 sehr intuitiv ist.

Verweise

Recommended Posts