Comment utiliser JUnit et Hamcrest ensemble?

Je ne comprends pas comment JUnit 4.8 devrait fonctionner avec les matchers Hamcrest. Il y a des matchers définis dans junit-4.8.jar dans org.hamcrest.CoreMatchers . Dans le même temps, il y a d’ autres joueurs dans hamcrest-all-1.1.jar dans org.hamcrest.Matchers . Alors, où aller? Dois-je explicitement inclure hamcrest JAR dans le projet et ignorer les corrélateurs fournis par JUnit?

En particulier, le mater empty() m’intéresse et ne peut le trouver dans aucun de ces jars. J’ai besoin de quelque chose d’autre 🙂

Et une question philosophique: pourquoi JUnit a-t-il inclus le package org.hamcrest dans sa propre dissortingbution au lieu de nous encourager à utiliser la bibliothèque hamcrest originale?

junit fournit de nouvelles méthodes d’affirmation de contrôle appelées assertThat () qui utilisent des correspondances et devraient fournir un code de test plus lisible et de meilleurs messages d’erreur.

Pour l’utiliser, certains jalons sont inclus dans junit. Vous pouvez commencer avec ces tests de base.

Si vous voulez utiliser plus d’affineurs, vous pouvez les écrire vous-même ou utiliser la librairie hamcrest.

L’exemple suivant montre comment utiliser le matcher vide sur une ArrayList:

 package com.test; import static org.hamcrest.Matchers.empty; import static org.hamcrest.Matchers.is; import static org.junit.Assert.assertThat; import java.util.ArrayList; import java.util.List; import org.junit.Test; public class EmptyTest { @Test public void testIsEmpty() { List myList = new ArrayList(); assertThat(myList, is(empty())); } } 

(J’ai inclus le fichier hamcrest-all.jar dans mon chemin de construction)

Si vous utilisez un Hamcrest avec une version supérieure ou égale à 1.2, vous devez utiliser le junit-dep.jar . Ce pot n’a pas de classes Hamcrest et vous évitez donc les problèmes de chargement de classes.

Depuis JUnit 4.11, le junit.jar lui-même ne possède aucune classe Hamcrest. junit-dep.jar plus junit-dep.jar .

Ne répondant pas exactement à votre question, vous devez absolument essayer l’API d’assertions fluides FEST-Assert . Il est en concurrence avec Hamcrest, mais dispose d’une API beaucoup plus facile avec une seule importation statique requirejse. Voici le code fourni par cpater en utilisant FEST:

 package com.test; import java.util.ArrayList; import java.util.List; import org.junit.Test; import static org.fest.assertions.Assertions.assertThat; public class EmptyTest { @Test public void testIsEmpty() { List myList = new ArrayList(); assertThat(myList).isEmpty(); } } 

EDIT: Maven coordonne:

  org.easytesting fest-assert 1.4 test  

De plus, si JUnit 4.1.1 + Hamcrest 1.3 + Mockito 1.9.5 sont utilisés, assurez-vous que mockito-all n’est pas utilisé. Il contient des classes de base Hamcrest. Utilisez plutôt mockito-core. La configuration ci-dessous fonctionne:

  org.hamcrest hamcrest-all 1.3 test   org.mockito mockito-core 1.9.5 test   hamcrest-core org.hamcrest     junit junit 4.1.1 test   hamcrest-core org.hamcrest    

Comme les versions changent tout le temps, je poste pour informer les gens que depuis le 2 décembre 2014, les instructions sont disponibles sur http://www.javacodegeeks.com/2014/03/how-to-test-dependencies-in -a-maven-project-junit-mockito-hamcrest-assertj.html a fonctionné pour moi. Je n’ai pas utilisé AssertJ cependant, juste ceux-ci:

  junit junit 4.11 test   org.mockito mockito-core 1.9.5 test   org.hamcrest hamcrest-core 1.3 test   org.hamcrest hamcrest-library 1.3 test   org.objenesis objenesis 1.3 test  

Pourquoi JUnit a-t-il inclus le package org.hamcrest dans sa propre dissortingbution au lieu de nous encourager à utiliser la bibliothèque hamcrest originale?

Je suppose que c’est parce qu’ils voulaient que l’ assertThat fasse partie de JUnit. Cela signifie que la classe org.hamcrest.Matcher doit importer l’interface org.hamcrest.Matcher et qu’elle ne peut le faire que si JUnit dépend de Hamcrest ou inclut (au moins une partie de) Hamcrest. Et je suppose qu’inclure une partie était plus facile, de sorte que JUnit serait utilisable sans aucune dépendance.

JUnit-4.12 et JUnit-Dep-4.10 ont des dépendances Hamcrest en fonction des fichiers .xml respectifs.

Une enquête plus approfondie montre que, bien que la dépendance ait été faite dans les fichiers .xml, la source et les classes dans les fichiers JAR. Cela semble être un moyen d’exclure la dépendance dans build.gradle … en la testant pour que tout rest propre.

Juste un fyi