Es funktioniert einwandfrei, wenn es von der Befehlszeile aus mit Ant ausgeführt wird. Aber wenn es von IntelliJ ausgeführt wird, schlägt es fehl mit:
java.lang.NoSuchMethodError: org.hamcrest.Matcher.describeMismatch(Ljava/lang/Object;Lorg/hamcrest/Description;)V
at org.hamcrest.MatcherAssert.assertThat(MatcherAssert.java:18)
at org.hamcrest.MatcherAssert.assertThat(MatcherAssert.java:8)
at com.netflix.build.MyTest.testmyStuff(MyTest.java:40)
Meine Vermutung ist, dass es das falsche hamcrest.MatcherAssert verwendet. Wie finde ich heraus, welches hamcrest.MatcherAssert es verwendet (dh welche JAR-Datei es für hamcrest.MatcherAssert verwendet)? AFAICT, die einzigen Hamcrest-Jars in meinem Klassenpfad sind 1.3.RC2.
Verwendet IntelliJ IDEA eine eigene Kopie von JUnit oder Hamcrest?
Wie gebe ich den Laufzeit-CLASSPATH aus, den IntelliJ verwendet?
Garret Hall
Stellen Sie sicher, dass Oberschenkel jar ist im Importauftrag höher als Ihre JUnit Krug.
JUnit kommt von selbst org.hamcrest.Matcher Klasse, die wahrscheinlich stattdessen verwendet wird.
Sie können die auch herunterladen und verwenden junit-dep-4.10.jar stattdessen ist das JUnit ohne die Hamcrest-Klassen.
mockito enthält auch die Hamcrest-Klassen, daher müssen Sie es möglicherweise auch verschiebenneu anordnen
OP sagte, dass sie bereits das ‘-dep-‘-Glas verwenden. Aber Ihre Vermutung, dass es die Matcher-Klasse aus dem JUnit-Jar verwendet, klingt richtig. Es ist also wahrscheinlich, dass die IDE ihre eigene Kopie von JUnit verwendet.
– Tyler
24. Oktober 11 um 20:40 Uhr
Ich habe die IntelliJ-Kopie von junit.jar und junit-4.8.jar entfernt, junit-dep-4.10.jar in das lib/-Verzeichnis von IntelliJ installiert, und das Problem tritt immer noch auf.
Ganz so wie die neuen Versionen von mockito beinhalten hamcrest auch gleich Powermock!
– Tom Parkinson
17. Dezember 13 um 9:33 Uhr
Sollte das Mockito-Core statt Mockito-All sein?
– Benutzer944849
13. Januar 14 um 21:38 Uhr
Sie könnten nur den Kern hinzufügen, wenn Sie ihn nur im Tempo benötigen, aber das oben Genannte sollte in allen Fällen funktionieren. Die Reihenfolge der Abhängigkeiten ist das wichtige Bit mvn 3 beginnt von oben in der Reihenfolge der Priorität.
– Tom Parkinson
14. Januar 14 um 08:15 Uhr
Sie sollten Mockito-All NICHT einschließen, da dies Hamcrest 1.1 enthält, sondern Mockito-Core einschließen und Hancrest davon ausschließen (was Sie nicht von allen tun können).
– Ulf Lindback
21. November 14 um 10:12 Uhr
“Wenn möglich nur Mockito-Core einbeziehen.”. OK, warum verwendet diese Antwort dann immer noch mockito-all ?
– Stealth-Rabbi
17. Januar 20 um 15:56 Uhr
Noel Jap
Das Problem war, dass das falsch war hamcrest.Matcher, nicht hamcrest.MatcherAssert, Klasse wurde verwendet. Das wurde aus einer junit-4.8-Abhängigkeit eingezogen, die eine meiner Abhängigkeiten spezifizierte.
Um zu sehen, welche Abhängigkeiten (und Versionen) aus welcher Quelle beim Testen enthalten sind, führen Sie Folgendes aus:
mvn dependency:tree -Dscope=test
Ich hatte das gleiche Problem. Ich habe JUnit-dep und Hamcrest-core verwendet, aber Powermock war früher im Pom aufgeführt, was dazu führte, dass JUnit vor JUnit-dep und Hamcrest enthalten war.
– Johannes B
3. November 11 um 13:10 Uhr
Auch mockito-all enthält einige Hamcrest-Klassen. Es ist besser, Mockito-Core zu verwenden und die Hamcrest-Abhängigkeit auszuschließen.
– Brambo
24. April 2012 um 9:39 Uhr
Bin gerade auf das gleiche Problem gestoßen. Die Lösung bestand darin, die Junit-Version auf 4.11 zu aktualisieren, die mit Hamcrest 1.3 kompatibel ist (dh “Klassen enthält von”)
– r3mbol
12. September 13 um 8:59 Uhr
Für diejenigen, bei denen alle Vorschläge nicht so gut funktioniert haben (Abhängigkeitsreihenfolge, Ausschlüsse, Entfernen von Ersetzen -all mit -core, etc…): Ich musste hamcrest wieder auf Version 1.1 umstellen und jetzt funktioniert alles wieder.
– Felix Hagspiel
11. Januar 19 um 10:07 Uhr
Bei mir hat es funktioniert, als ich meinen Import auf geändert habe import static org.mockito.Matchers.anyString; von import static org.mockito.ArgumentMatchers.anyString;
– Shrikant Prabhu
17. Januar 19 um 10:18 Uhr
Das Folgende sollte heute am richtigsten sein. Beachten Sie, dass junit 4.11 von hamcrest-core abhängt, daher sollten Sie dies überhaupt nicht angeben müssen, da mockito-all nicht verwendet werden kann beinhaltet (hängt nicht von ab) Hamcrest 1.1
Gleiche für mich. Das Anordnen von Abhängigkeiten in dieser Reihenfolge hilft Maven, transitive Deps korrekt aufzulösen. Das ausdrückliche Ausschließen von Hamcrest aus Mockito-Core oder Mockito-All könnte jedoch sicherer sein, falls jemand Deps in Ihrem Pom neu anordnet.
– Matte
26. Januar 17 um 14:48 Uhr
Kai
Ich weiß, dass dies ein alter Thread ist, aber was das Problem für mich gelöst hat, war das Hinzufügen des Folgenden zu meinen build.gradle-Dateien. Wie bereits oben erwähnt, gibt es ein Kompatibilitätsproblem mit mockito-all
Gleiche für mich. Das Anordnen von Abhängigkeiten in dieser Reihenfolge hilft Maven, transitive Deps korrekt aufzulösen. Das ausdrückliche Ausschließen von Hamcrest aus Mockito-Core oder Mockito-All könnte jedoch sicherer sein, falls jemand Deps in Ihrem Pom neu anordnet.