Getting "NoSuchMethodError: org.hamcrest.Matcher.describeMismatch" when running test in IntelliJ 10.5

Question

I'm using JUnit-dep 4.10 and Hamcrest 1.3.RC2.

I've created a custom matcher that looks like the following:

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 */
    }
}

It works perfectly fine when run from the command line using Ant. But when run from IntelliJ, it fails with:

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)

My guess is that it's using the wrong hamcrest.MatcherAssert. How do I find which hamcrest.MatcherAssert it's using (ie which jar file it's using for hamcrest.MatcherAssert)? AFAICT, the only hamcrest jars in my classpath is 1.3.RC2.

Is IntelliJ IDEA using it's own copy of JUnit or Hamcrest?

How do I output the runtime CLASSPATH that IntelliJ is using?

score 277 · Answer 1 · edited Jul 15 '15 at 00:29

277

Make sure the hamcrest jar is higher on the import order than your JUnit jar.

JUnit comes with its own org.hamcrest.Matcher class that is probably being used instead.

You can also download and use the junit-dep-4.10.jar instead which is JUnit without the hamcrest classes.

mockito also has the hamcrest classes in it as well, so you may need to move\reorder it as well

edited Jul 15 '15 at 00:29

javamonkey79

16,837
35
104
166

answered Oct 24 '11 at 15:47

Garrett Hall

27,772
10
56
73

1

OP said they were already using the '-dep-' jar. But your guess that it's using the Matcher class from the JUnit jar sounds right. So it's probably that the IDE is using its own copy of JUnit. – MatrixFrog Oct 24 '11 at 20:40
2

I removed IntelliJ's copy of junit.jar and junit-4.8.jar, installed junit-dep-4.10.jar into IntelliJ's lib/ directory, and the problem still occurs. – Noel Yap Oct 24 '11 at 20:59
Have you checked the .classppath to make sure there are no other JUnit entries? – Garrett Hall Oct 24 '11 at 21:02
I just checked the runtime classpath as given on the first line when debugging a test. The only jar file that has MatcherAssert is hamcrest-core-1.3. – Noel Yap Oct 24 '11 at 21:19
Maybe using junit-dep no longer solves this: [the junit:junit-dep artifact only consists of a POM pointing to junit:junit now](https://github.com/KentBeck/junit/pull/421)? And for future reference, a bug report: [4.9 and 4.10 "junit" artifacts in Maven Central have hamcrest as dependency defined while in "junit" artifact the hamcrest classes are already included](https://github.com/KentBeck/junit/issues/332). – Arjan Sep 05 '12 at 08:22
excellent man! I was facing this issue in OSGI environment...when I had Junit 4 in my dependencies...I could not see hamcrest plugin when I searched for it. However, if I removed Junit and searched...I did find it in the list. – Vikram Apr 12 '13 at 16:16
8

JUnit 4.11 is compatible with Hamcrest 1.3 and JUnit 4.10 is compatible with Hamcrest 1.1 http://search.maven.org/remotecontent?filepath=junit/junit-dep/4.10/junit-dep-4.10.pom – Muthu May 15 '14 at 12:04
25

make sure you are NOT using mockito-all, but instead mockito-core with an exclusion of hamcrest – Ulf Lindback Nov 21 '14 at 10:19
1

It is 7:33 PM in the office an I am working on an important feature that I must deliver before go out in a Vacation and It is Friday, I am in that Vacation next week !!!!!! How da hell I could get this error now !!! – Adelin Jul 15 '16 at 16:34
2

"higher on the import" what do you mean ? – Adelin Jul 15 '16 at 16:34
This applies to Eclipse too. – ojchase Feb 27 '19 at 23:29
I've got the same clash with`JUnit 4.11` and `Hamcrest 2.0.0.0`. – flaz14 Mar 06 '19 at 07:36

score 175 · Answer 2 · edited Dec 09 '16 at 11:11

175

This problem also arises when you have mockito-all on your class path, which is already deprecated.

If possible just include mockito-core.

Maven config for mixing junit, mockito and 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>

edited Dec 09 '16 at 11:11

marcin

2,865
2
10
12

answered May 24 '13 at 12:49

Tom Parkinson

2,043
1
10
11

This is exactly the hint I needed. The idea simply is to check all this über jars for hidden dependencies. Or better not to be lazy and don't use them at all. – Oliver Dec 17 '13 at 09:09
2

Quite as the new versions of mockito include hamcrest also same with powermock! – Tom Parkinson Dec 17 '13 at 09:33
3

Should that be mockito-core instead of mockito-all? – user944849 Jan 13 '14 at 21:38
3

You could include just core if you only need it in pace of all however the above should work in all cases. The order of the dependencies is the important bit mvn 3 starts from the top in order of priority. – Tom Parkinson Jan 14 '14 at 08:15
3

You should NOT include mockito-all since that includes hamcrest 1.1, instead include mockito-core and exclude hancrest from it (which you cannot do from all) – Ulf Lindback Nov 21 '14 at 10:12
Saved me some hours. Thanks! – Bruno P. Kinoshita Apr 10 '16 at 00:32
1

"If possible just include mockito-core.". OK, so then why does this answer still use mockito-all ? – Stealth Rabbi Jan 17 '20 at 15:56

score 62 · Accepted Answer · edited Sep 25 '17 at 11:33

62

The problem was that the wrong hamcrest.Matcher, not hamcrest.MatcherAssert, class was being used. That was being pulled in from a junit-4.8 dependency one of my dependencies was specifying.

To see what dependencies (and versions) are included from what source while testing, run:

mvn dependency:tree -Dscope=test

edited Sep 25 '17 at 11:33

Alex

7,405
5
46
72

answered Oct 24 '11 at 21:48

Noel Yap

15,499
17
77
123

5

I had the same issue. I was using JUnit-dep and Hamcrest-core but I had Powermock listed earlier in the pom which was resulting in JUnit being included before JUnit-dep and Hamcrest. – John B Nov 03 '11 at 13:10
9

Also mockito-all includes some Hamcrest classes. It's better to use mockito-core and exclude the hamcrest dependency. – Brambo Apr 24 '12 at 09:39
3

Just stumbled upon the exact same problem. Solution was upping junit version to 4.11 which is compatible (i.e. "contains classes from") with hamcrest 1.3 – r3mbol Sep 12 '13 at 08:59
For those where all the suggestions did not work as well (Dependency order, exlusions, removing replace `-all` with `-core`, etc...): I had to change hamcrest back to version 1.1 and now everything works again. – Felix Hagspiel Jan 11 '19 at 10:07
1

for me it worked when I changed my import to `import static org.mockito.Matchers.anyString;` from `import static org.mockito.ArgumentMatchers.anyString;` – Shrikant Prabhu Jan 17 '19 at 10:18

score 28 · Answer 4 · answered Nov 21 '14 at 10:17

The following should be the most correct today. Note, junit 4.11 depends on hamcrest-core, so you shouldn't need to specify that at all, mockito-all cannot be used since it includes (not depends on) 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>

Exclusion from `mockito-all` helped to me, not `mockito-core`. Also declaring Hamcrest before Mockito in `pom.xml` works. — Kirill, Jan 18 '18 at 21:55

score 14 · Answer 5 · edited May 07 '14 at 09:45

14

This worked for me after struggling a bit

<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>

edited May 07 '14 at 09:45

Oliver

3,186
4
27
51

answered Apr 12 '14 at 20:13

Raul

1,759
1
16
30

Same for me. Putting dependencies in this order helps maven to resolve transitive deps correctly. Explicitely excluding hamcrest from mockito-core or mockito-all might be safer though, in case someone reorders deps in your pom. – Mat Jan 26 '17 at 14:48

score 5 · Answer 6 · answered May 22 '17 at 06:11

I know this is an old thread but what solved the issue for me was adding the following to my build.gradle files. As already stated above there is a compatibility issue with mockito-all

Possibly useful post:

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'

score 4 · Answer 7 · edited Feb 05 '15 at 23:40

4

Try

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

instead of

expectMessage(message)

You may write a custom ExpectedException or utility method to wrap up the code.

edited Feb 05 '15 at 23:40

mlegge

6,303
3
32
59

answered Feb 05 '15 at 23:14

Qiang Li

41
1

zeinkap · Answer 8 · 2020-07-06T17:43:37.380

As of July, 2020 the following dependencies in pom.xml worked for me:

<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>

With this 4.13 junit library and hamcrest, it uses hamcrest.MatcherAssert when asserting and throws exception- enter image description here

score 1 · Answer 9 · answered Nov 27 '17 at 23:00

Despite the fact that this is a very old question and probably many of the beforementioned ideas solved many problems, I still want to share the solution with the community that fixed my problem.

I found that the problem was a function called "hasItem" which I was using to check whether or not a JSON-Array contains a specific item. In my case I checked for a value of type Long.

And this led to the problem.

Somehow, the Matchers have problems with values of type Long. (I do not use JUnit or Rest-Assured so much so idk. exactly why, but I guess that the returned JSON-data does just contain Integers.)

So what I did to actually fix the problem was the following. Instead of using:

long ID = ...;

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

you just have to cast to Integer. So the working code looked like this:

long ID = ...;

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

That's probably not the best solution, but I just wanted to mention that the exception can also be thrown because of wrong/unknown data types.

score 1 · Answer 10 · answered Feb 09 '19 at 12:38

In my case, I had to exclude an older hamcrest from 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>

score 0 · Answer 11 · answered May 10 '16 at 17:48

What worked for me was excluding the hamcrest group from the junit test compile.

Here is the code from my build.gradle:

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

If you're running IntelliJ you may need to run gradle cleanIdea idea clean build to detect the dependencies again.

score 0 · Answer 12 · answered May 30 '16 at 13:20

I know that's not the best answer, but if you can't get the classpath working, this is a plan B solution.

In my test classpath, I added the following interface with a default implementation for the describeMismatch method.

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_();
}

score 0 · Answer 13 · answered Jan 06 '19 at 20:09

I have a gradle project and when my build.gradle dependencies section looks like this:

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'
}

it leads to this exception:

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)

to fix this issue, I've substituted "mockito-all" with "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'
}

The explanation between mockito-all and mockito-core can be found here: https://solidsoft.wordpress.com/2012/09/11/beyond-the-mockito-refcard-part-3-mockito-core-vs-mockito-all-in-mavengradle-based-projects/

mockito-all.jar besides Mockito itself contains also (as of 1.9.5) two dependencies: Hamcrest and Objenesis (let’s omit repackaged ASM and CGLIB for a moment). The reason was to have everything what is needed inside an one JAR to just put it on a classpath. It can look strange, but please remember than Mockito development started in times when pure Ant (without dependency management) was the most popular build system for Java projects and the all external JARs required by a project (i.e. our project’s dependencies and their dependencies) had to be downloaded manually and specified in a build script.

On the other hand mockito-core.jar is just Mockito classes (also with repackaged ASM and CGLIB). When using it with Maven or Gradle required dependencies (Hamcrest and Objenesis) are managed by those tools (downloaded automatically and put on a test classpath). It allows to override used versions (for example if our projects uses never, but backward compatible version), but what is more important those dependencies are not hidden inside mockito-all.jar what allows to detected possible version incompatibility with dependency analyze tools. This is much better solution when dependency managed tool is used in a project.

score 0 · Answer 14 · answered Aug 14 '19 at 10:57

This worked for me. No need to exclude anything. I just used mockito-core instead 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'

score 0 · Answer 15 · answered Mar 30 '21 at 13:19

For jUnit 4.12, the following dependency combination fixed my issue.

<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>

Getting "NoSuchMethodError: org.hamcrest.Matcher.describeMismatch" when running test in IntelliJ 10.5

15 Answers15

Linked

Related