assertEquals(Object, Object)
de JUnit4 / JUnit 5 ou assertThat(actual, is(expected));
de Hamcrest proposé dans les autres réponses ne fonctionneront que comme les deux equals()
et toString()
sont remplacés pour les classes (et profondément) des objets comparés.
Cela est important car le test d'égalité dans l'assertion s'appuie sur equals()
et le message d'échec du test s'appuie sur toString()
les objets comparés.
Pour les classes intégrées telles que String
, Integer
et ainsi de suite ... pas de problème car elles remplacent à la fois equals()
et toString()
. Il est donc parfaitement valable d'affirmer List<String>
ou List<Integer>
avec assertEquals(Object,Object)
.
Et à ce sujet: vous devez surcharger equals()
dans une classe parce que cela a du sens en termes d'égalité d'objet, pas seulement pour faciliter les assertions dans un test avec JUnit.
Pour faciliter les affirmations, vous avez d'autres moyens.
En tant que bonne pratique, je préfère les bibliothèques d'assertion / matcher.
Voici une solution AssertJ .
org.assertj.core.api.ListAssert.containsExactly()
est ce dont vous avez besoin: il vérifie que le groupe réel contient exactement les valeurs données et rien d'autre, dans l'ordre indiqué dans le javadoc.
Supposons une Foo
classe où vous ajoutez des éléments et où vous pouvez les obtenir.
Un test unitaire de Foo
cela affirme que les deux listes ont le même contenu pourrait ressembler à ceci:
import org.assertj.core.api.Assertions;
import org.junit.jupiter.api.Test;
@Test
void add() throws Exception {
Foo foo = new Foo();
foo.add("One", "Two", "Three");
Assertions.assertThat(foo.getElements())
.containsExactly("One", "Two", "Three");
}
Un bon point d'AssertJ est que déclarer a List
comme attendu est inutile: cela rend l'assertion plus droite et le code plus lisible:
Assertions.assertThat(foo.getElements())
.containsExactly("One", "Two", "Three");
Mais les bibliothèques d'assertions / matrices sont indispensables car elles vont vraiment plus loin.
Supposons maintenant que Foo
cela ne stocke pas les instances String
s mais Bar
s.
C'est un besoin très courant. Avec AssertJ, l'assertion est encore simple à écrire. Mieux, vous pouvez affirmer que le contenu de la liste est égal même si la classe des éléments ne remplace pas equals()/hashCode()
alors que JUnit l'exige:
import org.assertj.core.api.Assertions;
import static org.assertj.core.groups.Tuple.tuple;
import org.junit.jupiter.api.Test;
@Test
void add() throws Exception {
Foo foo = new Foo();
foo.add(new Bar(1, "One"), new Bar(2, "Two"), new Bar(3, "Three"));
Assertions.assertThat(foo.getElements())
.extracting(Bar::getId, Bar::getName)
.containsExactly(tuple(1, "One"),
tuple(2, "Two"),
tuple(3, "Three"));
}
assertArrayEquals
nos jours. Utiliser en combinaison avecList#toArray
.