Comment utiliser JUnit et Hamcrest ensemble?
Je ne comprends pas comment JUnit 4.8 devrait fonctionner avec Hamcrest matchers. Il y a quelques matches définis à l'intérieur de junit-4.8.jar dans org.hamcrest.CoreMatchers . En même temps il y a quelques autres matchers dans hamcrest-all-1.1.jar dans org.hamcrest.Matchers . Alors, où aller? Dois-je inclure explicitement hamcrest JAR dans le projet et ignorer les matchers fournis par JUnit?
en particulier, je suis intéressé par empty() matcher et ne peut pas le trouver dans l'un de ces pots. J'ai besoin de quelque chose d'autre? :)
et une question philosophique: pourquoi JUnit a inclus org.hamcrest paquet dans sa propre distribution au lieu de nous encourager à utiliser la bibliothèque originale hamcrest?
8 réponses
junit fournit de nouvelles méthodes d'assertions de contrôle nommées assertThat () qui utilisent des Matchers et devraient fournir un code de test plus lisible et de meilleurs messages de défaillance.
pour utiliser ceci, il y a des connecteurs de base inclus dans junit. Vous pouvez commencer avec ceux-ci pour les tests de base.
si vous voulez utiliser plus de paillassons, vous pouvez les écrire vous-même ou utiliser le hamcrest lib.
L'exemple suivant montre comment utiliser le vide matcher sur une liste de tableaux:
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 hamcrest-all.jar dans mon buildpath)
si vous utilisez un Hamcrest avec une version supérieure ou égale à 1.2, vous devez utiliser le junit-dep.jar . Ce bocal n'a pas de classe Hamcrest et donc vous évitez les problèmes de chargement de classe.
depuis le 11 juin le junit.jar lui-même n'a pas de classes Hamcrest. Il n'y a plus besoin de junit-dep.jar .
pas exactement répondre à votre question, mais vous devriez certainement essayer FEST-Assert assertions fluent API. Il est en concurrence avec Hamcrest, mais dispose d'une API beaucoup plus facile avec une seule importation statique nécessaire. 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();
}
}
modifier: coordonnées Maven:
<dependency>
<groupId>org.easytesting</groupId>
<artifactId>fest-assert</artifactId>
<version>1.4</version>
<scope>test</scope>
</dependency>
aussi, si JUnit 4.1.1 + Hamcrest 1.3 + Mockito 1.9.5 sont utilisés, assurez-vous mockito-all n'est pas utilisé. Il contient les classes principales de Hamcrest. Utilisez mockito-core à la place. La configuration ci-dessous fonctionne:
<dependency>
<groupId>org.hamcrest</groupId>
<artifactId>hamcrest-all</artifactId>
<version>1.3</version>
<scope>test</scope>
</dependency>
<dependency>
<groupId>org.mockito</groupId>
<artifactId>mockito-core</artifactId>
<version>1.9.5</version>
<scope>test</scope>
<exclusions>
<exclusion>
<artifactId>hamcrest-core</artifactId>
<groupId>org.hamcrest</groupId>
</exclusion>
</exclusions>
</dependency>
<dependency>
<groupId>junit</groupId>
<artifactId>junit</artifactId>
<version>4.1.1</version>
<scope>test</scope>
<exclusions>
<exclusion>
<artifactId>hamcrest-core</artifactId>
<groupId>org.hamcrest</groupId>
</exclusion>
</exclusions>
</dependency>
étant donné que les versions changent constamment, je poste pour informer les gens qu'à partir du 2 décembre 2014, les instructions à http://www.javacodegeeks.com/2014/03/how-to-test-dependencies-in-a-maven-project-junit-mockito-hamcrest-assertj.html travaillait pour moi. Je n'ai pas utilisé AssertJ cependant, juste ceux-ci:
<dependency>
<groupId>junit</groupId>
<artifactId>junit</artifactId>
<version>4.11</version>
<scope>test</scope>
</dependency>
<dependency>
<groupId>org.mockito</groupId>
<artifactId>mockito-core</artifactId>
<version>1.9.5</version>
<scope>test</scope>
</dependency>
<dependency>
<groupId>org.hamcrest</groupId>
<artifactId>hamcrest-core</artifactId>
<version>1.3</version>
<scope>test</scope>
</dependency>
<dependency>
<groupId>org.hamcrest</groupId>
<artifactId>hamcrest-library</artifactId>
<version>1.3</version>
<scope>test</scope>
</dependency>
<dependency>
<groupId>org.objenesis</groupId>
<artifactId>objenesis</artifactId>
<version>1.3</version>
<scope>test</scope>
</dependency>
pourquoi JUnit inclus org.hamcrest package dans sa propre distribution au lieu de nous encourager à utiliser la bibliothèque originale de hamcrest?
je suppose que c'est parce qu'ils voulaient que le assertThat fasse partie de JUnit. Cela signifie donc que la classe Assert doit importer l'interface org.hamcrest.Matcher et elle ne peut pas le faire à moins que JUnit ne dépende de Hamcrest, ou inclut (au moins une partie de) Hamcrest. Et je pense notamment à la partie des il a plus facile, pour que JUnit soit utilisable sans aucune dépendance.
les deux JUnit-4.12 et JUnit-Dep-4.10 ont des dépendances de Hamcrest selon les respectives .des fichiers xml.
une enquête plus approfondie montre que, bien que la dépendance ait été faite dans le .les fichiers xml, la source et les classes dans les bocaux. Le semble être une manière d'exclure la dépendance dans la construction.gradle ... tester de garder tout propre.
juste un F. Y. I.
en 2018 en utilisant les bibliothèques les plus modernes:
configurations {
all {
testCompile.exclude group: "org.hamcrest", module: "hamcrest-core"
testCompile.exclude group: "org.hamcrest", module: "hamcrest-library"
}
}
dependencies {
testCompile("junit:junit:4.12")
// testCompile("org.hamcrest:hamcrest-library:1.3")
// testCompile("org.hamcrest:java-hamcrest:2.0.0.0")
testCompile("org.hamcrest:hamcrest-junit:2.0.0.0")
}