[JAVA] Informationen zu Validierungsmethoden in JUnit

Als ich neulich versuchte, JUnit 5 zu spät zu verwenden, versicherte ich, dass das weg war. Es scheint, dass die Richtlinie darin besteht, das zu verwenden, was der Benutzer für die Behauptung mag.

Also über die in JUnit verwendete Verifizierungsmethode Betrachten wir die Verwendungskandidaten, einschließlich der bisher verwendeten. org.junit.Assert.assertEquals Traditionelle Methode. Ich wurde betreut, als ich ein neuer Angestellter war. Es wird jetzt nicht viel verwendet, weil es assertThat (sollte) hat.

@Test
public void test01() {
    int sum = add(30, 70);
    assertEquals(100, sum);
}
Es ist schwierig, die erwarteten und gemessenen Werte zu verstehen
Laut Javadoc ist links der erwartete Wert und rechts der gemessene Wert, aber ich vergesse ihn oft.
Bei der Entwicklung eines Teams schreiben einige Leute es in umgekehrter Reihenfolge, was später zu Verwirrung führen kann.
Einige Leute sagen vielleicht: "Es spielt keine Rolle, welche", aber ich persönlich fühle mich unwohl mit einer Fehlermeldung, bei der der erwartete Wert und der gemessene Wert umgekehrt werden.

java.lang.AssertionError: expected:<0> but was:<100>


</dd>
 <dt> Es kann nur eine Übereinstimmungsbeurteilung unterstützt werden </ dt>
 Der Name der <dd> -Methode ist gleich, daher nur natürlich. <br> In anderen Fällen als dem Match-Urteil sollte assertTrue verwendet werden, das später beschrieben wird. </ dd> </ dl>

 org.junit.Assert.assertTrue
 Eine traditionelle Methode wie assertEquals. Dies wurde auch erledigt, als ich ein neuer Mitarbeiter war.
 Da ein Boolescher Wert als Argument verwendet wird, ist es üblich, einen Vergleichsausdruck oder eine Beurteilungsmethode zu übergeben, die einen Booleschen Wert zur Überprüfung zurückgibt.

```java
@Test
public void test02() {
    int sum = add(30, 70);
    assertTrue(sum > 50);
}
Fehlermeldung ist schwer zu verstehen Ich bekomme keine Nachricht wie
.
Wenn Sie JUnit mit CI spielen möchten, ist dies die Option, die Sie nicht nutzen möchten.

org.junit.Assert.assertThat Eingeführt von JUnit 4. Es war Mainstream in JUnit 4. Überprüfen Sie dies, indem Sie den gemessenen Wert als erstes Argument und org.hamcrest.Matcher als zweites Argument übergeben. Seien Sie vorsichtig, da die gemessenen und erwarteten Werte das Gegenteil von assert Equals sind.

Fast alle Überprüfungen sollten mit dieser Behauptung möglich sein, da eine Fülle von Matchern bereitgestellt wird. Der folgende Artikel war sehr einfach zu verstehen, wie Matcher verwendet wird, daher werde ich ihn vorstellen.

■ Verwendung der in Matchers of Hamcrest definierten Methode https://qiita.com/opengl-8080/items/e57dab6e1fa5940850a3

@Test
public void test04() {
    int sum = add(30, 70);
    assertThat(sum, is(100));
}

@Test
public void test05() {
    String userName = "Yamada Taro";
    assertThat(userName, containsString("Ta"));
}
Gut lesbare Validierungssyntax Es ist leicht zu lesen, wenn es als englischer Satz betrachtet wird, z. B.
, dass die Summe 100 ist. Es ist auch möglich, die Wahrheit des erwarteten Wertes umzukehren, indem
not () kombiniert wird.
Matcher kann angepasst werden Durch Erstellen eines eigenen
Matchers können Sie eine projektspezifische Überprüfung durchführen.
Es ist großartig, dass Sie die Fehlermeldung selbst definieren können.

org.assertj.core.api.Assertions.assertThat Persönlich mein Favorit im Moment. Ich würde dies gerne nutzen, wenn ich von nun an mit der Implementierung von JUnit beginne. Der große Unterschied zu JUnits Behauptung besteht darin, dass das Argument nur der gemessene Wert ist und die Überprüfung des erwarteten Werts danach in der Methodenkette durchgeführt werden kann.

@Test
public void test01() {
    String userName = "Suzuki Jiro";
    assertThat(userName).contains("Ji");
}
    
@Test
public void test02() {
    int sum = add(30, 70);
    assertThat(sum).isGreaterThan(50);
}
IDE zeigt Methoden zur Kandidatenvalidierung
Junits assertThat gibt eine statische Validierungsmethode als zweites Argument an, was überraschend schmerzhaft ist. Wenn Sie es nicht sehr oft verwenden, werden Sie sich nicht an den Namen der Überprüfungsmethode erinnern. Bei Verwendung von assertThat von
AssertJ wird in der IDE die Kandidatenmethode angezeigt, die dem Typ des gemessenen Werts entspricht, da die Validierungsmethode der von assertThat zurückgegebenen Instanz aufgerufen wird.
Ich war sehr dankbar, als ich es tatsächlich benutzte. assertjStr.png assertjInt.png

Ich werde die Überprüfungsmethode von AssertJ vorstellen, da dieser Artikel gut organisiert und leicht zu verstehen war.

■ J-Version bestätigen: Liste der Überprüfungsmethoden, die häufig beim Testen verwendet werden https://qiita.com/naotawool/items/6512ecbe2fd006dacfd2

com.google.truth.Truth.assertThat Eine von Google bereitgestellte Assertionsbibliothek. Obwohl offiziell angepriesen, ist es AssertJ sehr ähnlich, mit einer fließenden Schnittstelle für Behauptungen. Wenn es bisher ähnlich ist, denke ich, dass AssertJ in Ordnung ist, aber Truth bietet eine benannte Methode, die den gemessenen Wert benennt, und es scheint, dass dies in der Fehlermeldung widergespiegelt werden kann. Es scheint andere einzigartige Elemente zu geben, aber sie wurden nicht untersucht ... Ich werde irgendwo ein Risiko eingehen und es mit AssertJ vergleichen.

@Test
public void test01() {
    String userName = "Suzuki Jiro";
    assertThat(userName).named("userName").contains("Ji");
}

@Test
public void test02() {
    int sum = add(30, 70);
    assertThat(sum).named("sum").isEqualTo(100);
}

schließlich

Daher werde ich vorerst AssertJs assertThat als Validierungsmethode verwenden. AssertJ hat auch eine Bibliothek namens AssertJ-DB für DB-Tests, daher möchte ich dies auch in Zukunft versuchen.

Recommended Posts