[JAVA] À propos des méthodes de validation dans JUnit

L'autre jour, quand j'ai essayé d'utiliser JUnit 5 tard, affirmer que c'était parti. Il semble que la politique consiste à utiliser ce que l'utilisateur aime pour l'assertion.

Donc, à propos de la méthode de vérification utilisée dans JUnit Considérons les candidats à l'utilisation, y compris ceux qui ont été utilisés jusqu'à présent. org.junit.Assert.assertEquals Méthode traditionnelle. J'ai été pris en charge lorsque j'étais un nouvel employé. Il n'est pas beaucoup utilisé maintenant parce qu'il a assertThat (devrait).

@Test
public void test01() {
    int sum = add(30, 70);
    assertEquals(100, sum);
}
La valeur attendue et la valeur mesurée sont difficiles à comprendre
Selon Javadoc, la gauche est la valeur attendue et la droite est la valeur mesurée, mais je l'oublie souvent.
Lors du développement d'une équipe, certaines personnes l'écrivent à l'envers, ce qui peut semer la confusion plus tard.
Certaines personnes peuvent dire: "Peu importe laquelle", mais je me sens personnellement mal à l'aise avec un message d'erreur dans lequel la valeur attendue et la valeur mesurée sont inversées.

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


</dd>
 <dt> Seul le jugement de correspondance peut être pris en charge </ dt>
 Le nom de la méthode <dd> est égal, donc ce n'est que naturel. <br> Dans les cas autres que le jugement de match, assertTrue, qui sera décrit plus loin, doit être utilisé. </ dd> </ dl>

 org.junit.Assert.assertTrue
 Une méthode traditionnelle comme assertEquals. Cela a également été pris en charge lorsque j'étais un nouvel employé.
 Puisqu'il prend un booléen comme argument, il est courant de transmettre une expression de comparaison ou une méthode de jugement qui renvoie un booléen pour vérification.

```java
@Test
public void test02() {
    int sum = add(30, 70);
    assertTrue(sum > 50);
}
Le message d'erreur est difficile à comprendre Je ne reçois pas de message comme
.
Si vous voulez jouer à JUnit avec CI, c'est l'option que vous ne voulez pas prendre.

org.junit.Assert.assertThat Introduit à partir de JUnit 4. C'était courant dans JUnit 4. Validez en passant la valeur mesurée comme premier argument et org.hamcrest.Matcher comme deuxième argument. Soyez prudent car les valeurs mesurées et attendues sont à l'opposé d'assert Equals.

Presque toutes les vérifications devraient être possibles avec cette affirmation, car une multitude de Matchers sont fournis. L'article suivant était très facile à comprendre sur l'utilisation de Matcher, je vais donc le présenter.

■ Comment utiliser la méthode définie dans Matchers of Hamcrest 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"));
}
Syntaxe de validation hautement lisible Il est facile à lire lorsqu'il est considéré comme une phrase en anglais, comme
affirmer que la somme est 100. Il est également possible d'inverser la vérité de la valeur attendue en combinant
not ().
Matcher peut être personnalisé En créant votre propre
Matcher, vous pouvez effectuer une vérification spécifique au projet.
C'est génial que vous puissiez définir vous-même le message d'erreur.

org.assertj.core.api.Assertions.assertThat Personnellement, ma préférée en ce moment. Je voudrais l'utiliser si je commence à implémenter JUnit à partir de maintenant. La grande différence par rapport à l'assertThat de JUnit est que l'argument n'est que la valeur mesurée et que la vérification de la valeur attendue après cela peut être effectuée dans la chaîne de méthodes.

@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 montre les méthodes de validation des candidats
L'assertThat de Junit spécifie une méthode de validation statique comme deuxième argument, ce qui est étonnamment douloureux. À moins que vous ne l'utilisiez très souvent, vous ne vous souviendrez pas du nom de la méthode de vérification. Lorsque vous utilisez assertThat de
AssertJ, la méthode de vérification de l'instance retournée par assertThat est appelée, de sorte que la méthode candidate qui correspond au type de la valeur mesurée est affichée dans l'EDI.
Je me suis senti très reconnaissant quand je l'ai utilisé. assertjStr.png assertjInt.png

Je vais vous présenter la méthode de vérification d'AssertJ car cet article était bien organisé et facile à comprendre.

■ Version Assert J: liste des méthodes de vérification souvent utilisées dans les tests https://qiita.com/naotawool/items/6512ecbe2fd006dacfd2

com.google.truth.Truth.assertThat Une bibliothèque d'assertions fournie par Google. Bien qu'officiellement vanté, il est très similaire à AssertJ et vous permet de faire des affirmations avec une interface fluide. Si c'est similaire à cela, je pense qu'AssertJ va bien, mais Truth fournit une méthode nommée qui nomme la valeur mesurée, et il semble que cela puisse être reflété dans le message d'erreur. Il semble y avoir d'autres éléments uniques, mais ils n'ont pas été étudiés ... Je vais tenter ma chance quelque part et la comparer avec AssertJ.

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

à la fin

Donc, pour le moment, je vais utiliser l'assertThat d'AssertJ comme méthode de validation. AssertJ a également une bibliothèque appelée AssertJ-DB pour les tests DB, je voudrais donc essayer ceci aussi à l'avenir.

Recommended Posts