Obteniendo “NoSuchMethodError: org.hamcrest.Matcher.describeMismatch” al ejecutar la prueba en IntelliJ 10.5

Estoy usando JUnit-dep 4.10 y Hamcrest 1.3.RC2.

Creé un marcador personalizado que se parece a lo siguiente:

public static class MyMatcher extends TypeSafeMatcher { @Override protected boolean matchesSafely(String s) { /* implementation */ } @Override public void describeTo(Description description) { /* implementation */ } @Override protected void describeMismatchSafely(String item, Description mismatchDescription) { /* implementation */ } } 

Funciona perfectamente bien cuando se ejecuta desde la línea de comando usando Ant. Pero cuando se ejecuta desde IntelliJ, falla con:

 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) 

Mi suposición es que está usando el hamcrest.MatcherAssert incorrecto. ¿Cómo encuentro qué hamcrest.MatcherAssert está usando (es decir, qué archivo jar está usando para hamcrest.MatcherAssert)? AFAICT, el único jarrón de Hamcrest en mi classpath es 1.3.RC2.

¿IntelliJ IDEA está usando su propia copia de JUnit o Hamcrest?

¿Cómo genero el tiempo de ejecución CLASSPATH que IntelliJ está utilizando?

Asegúrese de que el contenedor de Hamcrest esté más alto en el orden de importación que su jar JUnit .

JUnit viene con su propia clase org.hamcrest.Matcher que probablemente se esté utilizando en su lugar.

También puede descargar y usar el junit-dep-4.10.jar que es JUnit sin las clases de hamcrest.

mockito también tiene las clases de hamcrest, así que es posible que tengas que mover \ reordenarlo también

Este problema también surge cuando tienes mockito-all en tu ruta de clase, que ya está en desuso.

Si es posible, solo incluye el mockito-core .

Configuración de Maven para mezclar junit, mockito y hamcrest:

   org.hamcrest hamcrest-core 1.3 test   org.hamcrest hamcrest-library 1.3 test   org.mockito mockito-all 1.9.5 test   junit junit 4.11 test   

El problema era que se estaba utilizando la clase de hamcrest.Matcher , no hamcrest.MatcherAssert equivocada. Eso estaba siendo sacado de una dependencia junit-4.8 que una de mis dependencias estaba especificando.

Para ver qué dependencias (y versiones) se incluyen de qué fuente durante la prueba, ejecute:

 mvn dependency:tree -Dscope=test 

Lo siguiente debería ser el más correcto hoy. Tenga en cuenta que junit 4.11 depende de hamcrest-core, por lo que no debería necesitar especificarlo en absoluto, mockito-all no se puede usar ya que incluye (no depende de) hamcrest 1.1

  junit junit 4.11 test   org.mockito mockito-core 1.10.8 test   org.hamcrest hamcrest-core    

Esto funcionó para mí después de luchar un poco

  org.hamcrest hamcrest-all 1.3 test   org.mockito mockito-all 1.9.5 test   junit junit 4.11 test  

Tratar

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

en lugar de

expectMessage(message)

Puede escribir una ExpectedException personalizada o un método de utilidad para envolver el código.

Sé que este es un hilo viejo, pero lo que me solucionó el problema fue agregar lo siguiente a mis archivos build.gradle. Como ya se mencionó anteriormente, hay un problema de compatibilidad con mockito-all

Posiblemente una publicación útil:

 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' 

A pesar de que esta es una pregunta muy antigua y probablemente muchas de las ideas antes mencionadas resolvieron muchos problemas, aún quiero compartir la solución con la comunidad que solucionó mi problema.

Descubrí que el problema era una función llamada “hasItem” que estaba usando para verificar si un JSON-Array contiene o no un elemento específico. En mi caso, verifiqué un valor de tipo Long.

Y esto condujo al problema.

De alguna manera, los Matcher tienen problemas con los valores de tipo Long. (No uso tanto JUnit o Rest-Assured como para saber exactamente por qué, pero supongo que los datos JSON devueltos solo contienen números enteros).

Entonces, lo que hice para solucionar realmente el problema fue lo siguiente. En lugar de usar:

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

solo tienes que convertir a Entero. Entonces el código de trabajo se veía así:

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

Probablemente esa no sea la mejor solución, pero solo quería mencionar que la excepción también puede producirse debido a tipos de datos incorrectos / desconocidos.

Lo que funcionó para mí fue excluir el grupo de Hamcrest de la comstackción de prueba junit.

Aquí está el código de mi build.gradle:

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

Si está ejecutando IntelliJ, es posible que necesite ejecutar gradle cleanIdea idea clean build para detectar nuevamente las dependencias.

Sé que esa no es la mejor respuesta, pero si no puedes hacer que funcione el classpath, esta es una solución del plan B.

En mi classpath de prueba, agregué la siguiente interfaz con una implementación predeterminada para el método 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 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_(); } 
    Intereting Posts