Durante las pruebas de la suite, EasyMock dice que se esperaban 0 jugadores 1 registrado

matcher

Question

Así que he estado usando la extensión de clase de EasyMock por un tiempo. De repente recibo esta excepción, pero solo cuando ejecuto todo el conjunto de pruebas:

java.lang.IllegalStateException: 0 matchers expected, 1 recorded.
at org.easymock.internal.ExpectedInvocation.createMissingMatchers(ExpectedInvocation.java:42)
at org.easymock.internal.ExpectedInvocation.<init>(ExpectedInvocation.java:34)
at org.easymock.internal.ExpectedInvocation.<init>(ExpectedInvocation.java:26)
at org.easymock.internal.RecordState.invoke(RecordState.java:64)
at org.easymock.internal.MockInvocationHandler.invoke(MockInvocationHandler.java:24)
at org.easymock.internal.ObjectMethodsFilter.invoke(ObjectMethodsFilter.java:56)
at org.easymock.classextension.internal.ClassProxyFactory$1.intercept(ClassProxyFactory.java:74)
at com.protrade.soccersim.data.emulator.matrix.PositionCategoryMatrix$$EnhancerByCGLIB$$c5298a7.getPossession(<generated>)
at com.protrade.soccersim.data.emulator.stats.team.PossessionCalculatorUnitTest.testDeterminePossessionHomeWin(PossessionCalculatorUnitTest.java:45)

El código involucrado es esta pequeña belleza (recortada un poco):

 @Before
public void setUp() throws Exception {
homeTeam = createMock( PositionCategoryMatrix.class );
awayTeam = createMock( PositionCategoryMatrix.class );
...
}
@Test
public void testDeterminePossessionHomeWin() {
expect(homeTeam.getPossession()).andReturn( 0.15151515 );
expect(awayTeam.getPossession()).andReturn( 0.01515152 );
replay( homeTeam, awayTeam );
...
}

La excepción está siendo lanzada en la primera expectativa. Y realmente no tiene sentido. Dice que está obteniendo un emparejador, pero el método ni siquiera tiene una discusión. ¡Y por extraño que parezca, solo durante las suites de prueba! Estoy creando un nuevo simulacro en @Antes, por lo que no debería heredar nada de otro lugar (no es que algún otro método tenga un emparejador)

Entonces, ¿alguna idea?

Answer 1

¿Qué versión de Easymock estás usando?
Leí un post sobre el lanzamiento de v.2.5.2 y las versiones anteriores podrían tener un

error tonto en la captura

intenta usar Easymock 2.5.2+

Answer 2

Acabo de encontrarme con este problema y creo que me las arreglé para resolverlo. Para mí, fue debido a la prueba anterior (que está en una Clase diferente), donde estaba (incorrectamente) utilizando un emparejador EasyMock en un método Assert.assertEquals.

Parece que EasyMock no podía quejarse por el emparejador adicional informado hasta que se llamaron los primeros métodos de espera.

Answer 3

Estaba enfermo y cansado de ver esto con cada nueva base de código heredado con EasyMock con la que tenía que trabajar. Escriba una nueva prueba EasyMock por el libro y todas las pruebas aleatorias repentinas comienzan a fallar debido a que los Matchers nunca se capturaron. Así que eché un vistazo a cómo EasyMock almacena esos Matchers. Hace uso de una clase final LastControl, en esa clase hay algunos threadlocals donde se almacenan diferentes cosas. Uno de esos fue para los Matchers. La suerte dice que hay un método estático allí para sacar a todos los Matchers del threadlocal que todavía estaban allí. Así que esto me dio esta idea (con la ayuda de un colega, gracias Sven, él quería crédito)

/**
* Base class to make sure all EasyMock matchers are cleaned up. This is not pretty but it will work
*
* @author N069261KDS
*
*/
public class BaseTest {
@Before
public void before(){
LastControl.pullMatchers();
}
@After
public void after(){
LastControl.pullMatchers();
}
}

Básicamente, deje que su prueba que falla con el error de Matchers se extienda desde esta clase y se asegurará de que los Matchers estén limpios. Tenga en cuenta que esto es un problema. Las pruebas ofensivas deberían haber sido escritas en primer lugar. Pero si tienes que atravesar más de 5000 pruebas, este es el menor de los dos males. Espero que esto ayude a la gente!

Answer 4

Me estoy topando con un problema similar. Por lo que observé, incluso los retornos de los métodos se combinan usando Matchers. Entonces, si su primer método falla por alguna razón, el emparejador para la coincidencia de retorno todavía está en la pila. Esa podría ser una de las razones por las que estás viendo 1 matchers registrados incluso cuando tu método no acepta ningún argumento. Básicamente, la primera invocación del método nunca devolvió un valor.

Answer 5

Si bien es cierto que este puede ser un mensaje falso que resulta de un error "tonto" de EasyMock, también es muy probable que se deba al uso no válido de la API de EasyMock. En mi caso, el mensaje surgió de esta prueba JUnit 3.8 (y como usted, esto solo sucedió cuando ejecuté todo mi conjunto de pruebas, y solo a través de Maven, no Eclipse):

public void testSomething() {
// Set up
MyArgumentType mockArg = (MyArgumentType) EasyMock.anyObject(); // bad API usage
// Invoke the method under test
final String result = objectUnderTest.doSomething(mockArg);
// Verify (assertions, etc.)
...
}

En lugar de usar anyObject (), debería haber utilizado createMock (MyArgumentType.class) o una de sus variantes. No sé lo que estaba pensando, escribí millones de estas pruebas y usé la API correctamente.

El bit confuso es que la prueba que falla con el mensaje "número incorrecto de coincidencias" no es necesariamente (¿o alguna vez?) En la que usaste la API de manera incorrecta. Puede ser la primera prueba ejecutada después del buggy que contiene un método replay () o Verify (), pero no lo he verificado experimentalmente.

Answer 6

Tuve el mismo mensaje de error. Estaba (accidentalmente) utilizando una declaración isA () en la llamada en la clase bajo prueba

Es decir

classUnderTest.callStateChanged(calls, isA(LoggingOnlyListener.class));

cuando quise decir

classUnderTest.callStateChanged(calls, new LoggingOnlyListener());

Y fue la prueba DESPUÉS de esta que falló cada vez.