Получение NoSuchMethodError: org.hamcrest.Matcher.describeMismatch при запуске теста в IntelliJ 10.5

Убедитесь, что банка hamcrest выше в порядке импорта, чем банка JUnit.

JUnit имеет собственный класс org.hamcrest.Matcher, который, вероятно, используется вместо него.

Вы также можете загрузить и использовать вместо него junit-dep-4.10.jar, который представляет собой JUnit без классов hamcrest.

mockito также имеет классы hamcrest в нем, поэтому вам может потребоваться переместить \ изменить его порядок

Эта проблема также возникает, когда у вас есть mockito-all на пути к классу, который уже устарел.

Если возможно, просто включите mockito-core.

Конфигурация Maven для смешивания junit, mockito и hamcrest:

<dependencies>
  <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.mockito</groupId>
    <artifactId>mockito-all</artifactId>
    <version>1.9.5</version>
    <scope>test</scope>
  </dependency>
  <dependency>
    <groupId>junit</groupId>
    <artifactId>junit</artifactId>
    <version>4.11</version>
    <scope>test</scope>
  </dependency>
</dependencies>

Проблема заключалась в том, что использовался неправильный класс hamcrest.Matcher, а не hamcrest.MatcherAssert. Это было извлечено из зависимости junit-4.8, которую указывала одна из моих зависимостей.

Чтобы узнать, какие зависимости (и версии) из какого источника включены во время тестирования, запустите:

mvn dependency:tree -Dscope=test

Следующее сегодня должно быть наиболее правильным. Обратите внимание, что junit 4.11 зависит от hamcrest-core, поэтому вам не нужно указывать, что mockito-all вообще не может использоваться, поскольку он включает (не зависит от) hamcrest 1.1.

<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.10.8</version>
    <scope>test</scope>
    <exclusions>
        <exclusion>
            <groupId>org.hamcrest</groupId>
            <artifactId>hamcrest-core</artifactId>
        </exclusion>
    </exclusions>
</dependency>

Это сработало для меня после небольшой борьбы

<dependency>
    <groupId>org.hamcrest</groupId>
    <artifactId>hamcrest-all</artifactId>
    <version>1.3</version>
    <scope>test</scope>
 </dependency>

 <dependency>
    <groupId>org.mockito</groupId>
    <artifactId>mockito-all</artifactId>
    <version>1.9.5</version>
    <scope>test</scope>
 </dependency>

 <dependency>
    <groupId>junit</groupId>
    <artifactId>junit</artifactId>
    <version>4.11</version>
    <scope>test</scope>
 </dependency>

Я знаю, что это старый поток, но для меня проблема была решена путем добавления следующего в мои файлы build.gradle. Как уже было сказано выше, существует проблема совместимости с mockito-all

Возможно полезное сообщение:

testCompile ('junit:junit:4.12') {
    exclude group: 'org.hamcrest'
}
testCompile ('org.mockito:mockito-core:1.10.19') {
    exclude group: 'org.hamcrest'
}
testCompile 'org.hamcrest:hamcrest-core:1.3'

Пытаться

expect(new ThrowableMessageMatcher(new StringContains(message)))

вместо того

expectMessage(message)

Вы можете написать собственный ExpectedException или служебный метод, чтобы завершить код.

По состоянию на июль 2020 года у меня работали следующие зависимости в pom.xml:

<dependency>
    <groupId>junit</groupId>
    <artifactId>junit</artifactId>
    <version>4.13</version>
</dependency>
<dependency>
    <groupId>org.hamcrest</groupId>
    <artifactId>hamcrest</artifactId>
    <version>2.1</version>
</dependency>

С этой библиотекой junit 4.13 и hamcrest он использует hamcrest.MatcherAssert при утверждении и выдает исключение - введите описание изображения здесь

Несмотря на то, что это очень старый вопрос и, вероятно, многие из вышеупомянутых идей решили многие проблемы, я все же хочу поделиться решением с сообществом, которое устранило мою проблему.

Я обнаружил, что проблема заключалась в функции под названием «hasItem», которую я использовал, чтобы проверить, содержит ли JSON-массив конкретный элемент. В моем случае я проверил значение типа Long.

И это привело к проблеме.

Почему-то у Matchers возникают проблемы со значениями типа Long. (Я не использую JUnit или Rest-Assured так часто, поэтому я знаю почему, но я предполагаю, что возвращенные данные JSON содержат только целые числа.)

Итак, что я сделал, чтобы решить проблему, было следующее. Вместо использования:

long ID = ...;

...
.then().assertThat()
  .body("myArray", hasItem(ID));

вам просто нужно преобразовать в Integer. Итак, рабочий код выглядел так:

long ID = ...;

...
.then().assertThat()
  .body("myArray", hasItem((int) ID));

Вероятно, это не лучшее решение, но я просто хотел упомянуть, что исключение также может быть вызвано из-за неправильных / неизвестных типов данных.

В моем случае мне пришлось исключить более старый хамкрест из junit-vintage:

<dependency>
  <groupId>org.junit.vintage</groupId>
  <artifactId>junit-vintage-engine</artifactId>
  <scope>test</scope>
  <exclusions>
    <exclusion>
      <groupId>org.hamcrest</groupId>
      <artifactId>hamcrest-core</artifactId>
    </exclusion>
  </exclusions>
</dependency>
<dependency>
  <groupId>org.hamcrest</groupId>
  <artifactId>hamcrest</artifactId>
  <version>2.1</version>
  <scope>test</scope>
</dependency>

Что сработало для меня, так это исключение группы hamcrest из тестовой компиляции junit.

Вот код из моего build.gradle:

testCompile ('junit:junit:4.11') {
    exclude group: 'org.hamcrest'
}

Если вы используете IntelliJ, вам может потребоваться запустить gradle cleanIdea idea clean build, чтобы снова обнаружить зависимости.

Я знаю, что это не лучший ответ, но если вы не можете заставить работать путь к классам, это решение плана Б.

В моем тестовом пути к классам я добавил следующий интерфейс с реализацией по умолчанию для метода describeMismatch.

package org.hamcrest;

/**
 * PATCH because there's something wrong with the classpath. Hamcrest should be higher than Mockito so that the BaseMatcher
 * implements the describeMismatch method, but it doesn't work for me. 
 */
public interface Matcher<T> extends SelfDescribing {

    boolean matches(Object item);

    default void describeMismatch(Object item, Description mismatchDescription) {
        mismatchDescription.appendDescriptionOf(this).appendValue(item);
    }

    @Deprecated
    void _dont_implement_Matcher___instead_extend_BaseMatcher_();
}

У меня есть проект gradle, и когда мой раздел зависимостей build.gradle выглядит так:

dependencies {
    implementation group: 'org.apache.commons', name: 'commons-lang3', version: '3.8.1'

    testImplementation group: 'org.mockito', name: 'mockito-all', version: '1.10.19'
    testImplementation 'junit:junit:4.12'
//    testCompile group: 'org.mockito', name: 'mockito-core', version: '2.23.4'

    compileOnly 'org.projectlombok:lombok:1.18.4'
    apt 'org.projectlombok:lombok:1.18.4'
}

это приводит к этому исключению:

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)

чтобы решить эту проблему, я заменил "mockito-all" на "mockito-core".

dependencies {
    implementation group: 'org.apache.commons', name: 'commons-lang3', version: '3.8.1'

//    testImplementation group: 'org.mockito', name: 'mockito-all', version: '1.10.19'
    testImplementation 'junit:junit:4.12'
    testCompile group: 'org.mockito', name: 'mockito-core', version: '2.23.4'

    compileOnly 'org.projectlombok:lombok:1.18.4'
    apt 'org.projectlombok:lombok:1.18.4'
}

Объяснение между mockito-all и mockito-core можно найти здесь: https://solidsoft.wordpress.com/2012/09/11/запределами-the-mockito-refcard-part-3-mockito-core-vs-mockito-all-in-mavengradle-based-projects/

mockito-all.jar помимо самого Mockito также содержит (начиная с 1.9.5) две зависимости: Hamcrest и Objenesis (давайте на время опустим переупакованные ASM и CGLIB). Причина заключалась в том, чтобы иметь все необходимое в одном JAR, чтобы просто поместить его в путь к классам. Это может выглядеть странно, но, пожалуйста, помните, что разработка Mockito началась во времена, когда чистый Ant (без управления зависимостями) был самой популярной системой сборки для проектов Java, а все внешние JAR, необходимые для проекта (т.е. зависимости нашего проекта и их зависимости), имели загружаться вручную и указываться в сценарии сборки.

С другой стороны, mockito-core.jar - это просто классы Mockito (также с переупакованными ASM и CGLIB). При использовании с Maven или Gradle необходимые зависимости (Hamcrest и Objenesis) управляются этими инструментами (загружаются автоматически и помещаются в тестовый путь к классам). Это позволяет переопределить используемые версии (например, если в наших проектах используется никогда, но обратно совместимая версия), но, что более важно, эти зависимости не скрыты внутри mockito-all.jar, что позволяет обнаруживать возможную несовместимость версий с инструментами анализа зависимостей. Это гораздо лучшее решение, когда в проекте используется инструмент, управляемый зависимостями.

Это сработало для меня. Не нужно ничего исключать. Я просто использовал mockito-core вместо mockito-all

testCompile 'junit:junit:4.12'
testCompile group: 'org.mockito', name: 'mockito-core', version: '3.0.0'
testCompile group: 'org.hamcrest', name: 'hamcrest-library', version: '2.1'

Для jUnit 4.12 мою проблему устранила следующая комбинация зависимостей.

<dependency>
   <groupId>junit</groupId>
   <artifactId>junit</artifactId>
   <version>4.12</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>