Używam JUnit-dep 4.10 i Hamcrest 1.3.RC2.
Utworzyłem niestandardowy moduł dopasowywania, który wygląda następująco:
public static class MyMatcher extends TypeSafeMatcher<String> {
@Override
protected boolean matchesSafely(String s) {
/* implementation */
}
@Override
public void describeTo(Description description) {
/* implementation */
}
@Override
protected void describeMismatchSafely(String item, Description mismatchDescription) {
/* implementation */
}
}
Działa idealnie dobrze, gdy jest uruchamiany z wiersza poleceń za pomocą Ant. Ale uruchamiany z IntelliJ nie działa z:
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)
Domyślam się, że używa niewłaściwego hamcrest.MatcherAssert. Jak mogę znaleźć, którego hamcrest.MatcherAssert używa (tzn. Jakiego pliku jar używa dla hamcrest.MatcherAssert)? AFAICT, jedyne słoiki hamcrest w mojej ścieżce klas to 1.3.RC2.
Czy IntelliJ IDEA korzysta z własnej kopii JUnit lub Hamcrest?
Jak wyprowadzić środowisko wykonawcze CLASSPATH, którego używa IntelliJ?
Ten problem pojawia się także, gdy na ścieżce klasy znajduje się mockito-all , który jest już przestarzały.
Jeśli to możliwe, po prostu dołącz rdzeń-mockito .
Konfiguracja Maven do miksowania junit, mockito i hamcrest:
źródło
Problem polegał na tym , że użyto niewłaściwej
hamcrest.Matcher
, a niehamcrest.MatcherAssert
klasy. To było wyciągane z zależności junit-4.8, którą określiła jedna z moich zależności.Aby zobaczyć, jakie zależności (i wersje) są zawarte z jakiego źródła podczas testowania, uruchom:
źródło
-all
z-core
, etc ...): Musiałem zmienić hamcrest powrotem do wersji 1.1 i teraz wszystko działa ponownie.import static org.mockito.Matchers.anyString;
zimport static org.mockito.ArgumentMatchers.anyString;
Poniższe informacje powinny być dziś najbardziej poprawne. Uwaga, junit 4.11 zależy od rdzenia hamcrest, więc nie musisz wcale określać, że mockito-all nie może być używane, ponieważ obejmuje (nie zależy) hamcrest 1.1
źródło
mockito-all
pomocy mi pomogło, niemockito-core
. Deklarowanie Hamcrest przed Mockito wpom.xml
dziełach.To działało dla mnie po trochę zmaganiu się
źródło
Próbować
expect(new ThrowableMessageMatcher(new StringContains(message)))
zamiast
expectMessage(message)
Możesz napisać niestandardową
ExpectedException
lub użyteczną metodę, aby zakończyć kod.źródło
Wiem, że to stary wątek, ale rozwiązaniem mojego problemu było dodanie następujących plików do moich plików build.gradle. Jak już wspomniano powyżej, występuje problem ze zgodnością
mockito-all
Prawdopodobnie przydatny post :
źródło
Pomimo tego, że jest to bardzo stare pytanie i prawdopodobnie wiele z wyżej wymienionych pomysłów rozwiązało wiele problemów, nadal chcę podzielić się rozwiązaniem ze społecznością, która naprawiła mój problem.
Odkryłem, że problemem była funkcja o nazwie „hasItem”, której używałem do sprawdzenia, czy tablica JSON zawiera określony element. W moim przypadku sprawdziłem wartość typu Long.
To doprowadziło do problemu.
W jakiś sposób Matchery mają problemy z wartościami typu Long. (Nie używam JUnit ani Rest-Assured tak bardzo idk. Dokładnie dlaczego, ale wydaje mi się, że zwrócone dane JSON zawierają tylko liczby całkowite.)
Więc to, co zrobiłem, aby rozwiązać problem, było następujące. Zamiast używać:
po prostu musisz rzucić na Integer. Tak działający kod wyglądał następująco:
Prawdopodobnie nie jest to najlepsze rozwiązanie, ale chciałem tylko wspomnieć, że wyjątek może zostać zgłoszony również z powodu niewłaściwych / nieznanych typów danych.
źródło
To, co zadziałało, to wykluczenie grupy hamcrest z kompilacji testu junit.
Oto kod z mojego build.gradle:
Jeśli korzystasz z IntelliJ, może być konieczne uruchomienie w
gradle cleanIdea idea clean build
celu ponownego wykrycia zależności.źródło
Wiem, że nie jest to najlepsza odpowiedź, ale jeśli nie możesz uruchomić ścieżki klas, jest to rozwiązanie typu B.
W mojej testowej ścieżce klas dodałem następujący interfejs z domyślną implementacją dla metody replaceMismatch.
źródło
Mam projekt gradle i kiedy moja sekcja zależności build.gradle wygląda następująco:
prowadzi to do tego wyjątku:
Aby rozwiązać ten problem, podstawiłem „mockito-all” na „mockito-core”.
Wyjaśnienie między mockito-all i mockito-core można znaleźć tutaj: https://solidsoft.wordpress.com/2012/09/11/beyond-the-mockito-refcard-part-3-mockito-core-vs-mockito -wszystkie projekty oparte na mengengradle /
źródło
W moim przypadku musiałem wykluczyć starszy hamcrest z junit-vintage:
źródło
To zadziałało dla mnie. Nie musisz niczego wykluczać. Właśnie użyłem
mockito-core
zamiast tegomockito-all
źródło