Mockito: Intentar espiar el método es llamar al método original

Estoy usando Mockito 1.9.0. Quiero simular el comportamiento de un solo método de una clase en una prueba JUnit, así que tengo

final MyClass myClassSpy = Mockito.spy(myInstance);
Mockito.when(myClassSpy.method1()).thenReturn(myResults);

El problema es que, en la segunda línea, en myClassSpy.method1()realidad se llama, lo que resulta en una excepción. La única razón por la que estoy usando simulacros es para que luego, cada vez que myClassSpy.method1()se llame, no se llame al método real y myResultsse devuelva el objeto.

MyClasses una interfaz y myInstancees una implementación de eso, si eso importa.

¿Qué debo hacer para corregir este comportamiento de espionaje?

Permítanme citar la documentación oficial :

¡Importante truco para espiar objetos reales!

A veces es imposible de usar cuando (Objeto) para tropezar espías. Ejemplo:

List list = new LinkedList();
List spy = spy(list);

// Impossible: real method is called so spy.get(0) throws IndexOutOfBoundsException (the list is yet empty)
when(spy.get(0)).thenReturn("foo");

// You have to use doReturn() for stubbing
doReturn("foo").when(spy).get(0);

En tu caso es algo así como:

doReturn(resulstIWant).when(myClassSpy).method1();

Mi caso fue diferente de la respuesta aceptada. Estaba tratando de burlarme de un método de paquete privado para una instancia que no vivía en ese paquete

package common;

public class Animal {
  void packageProtected();
}

package instances;

class Dog extends Animal { }

y las clases de prueba

package common;

public abstract class AnimalTest<T extends Animal> {
  @Before
  setup(){
    doNothing().when(getInstance()).packageProtected();
  }

  abstract T getInstance();
}

package instances;

class DogTest extends AnimalTest<Dog> {
  Dog getInstance(){
    return spy(new Dog());
  }

  @Test
  public void myTest(){}
}

La compilación es correcta, pero cuando intenta configurar la prueba, invoca el método real.

Declarar el método protegido o público soluciona el problema, aunque no es una solución limpia.

En mi caso, usando Mockito 2.0, tuve que cambiar todos los any()parámetros a nullable()para detener la llamada real.

¡La respuesta de Tomasz Nurkiewicz parece no contar toda la historia!

NB Versión Mockito: 1.10.19.

Soy un Mockito newb, así que no puedo explicar el siguiente comportamiento: si hay un experto por ahí que pueda mejorar esta respuesta, por favor siéntase libre.

El método en cuestión aquí, NOgetContentStringValue es y NO . final static

Esta línea hace llamar el método original getContentStringValue:

doReturn( "dummy" ).when( im ).getContentStringValue( anyInt(), isA( ScoreDoc.class ));

Esta línea no llama al método original getContentStringValue:

doReturn( "dummy" ).when( im ).getContentStringValue( anyInt(), any( ScoreDoc.class ));

Por razones que no puedo responder, el uso isA()hace doReturnque falle el comportamiento pretendido (?) De "no llamar al método" .

Veamos las firmas de métodos involucradas aquí: ambos son staticmétodos de Matchers. El Javadoc dice que ambos regresan null, lo cual es un poco difícil de entender. Presumiblemente, el Classobjeto pasado mientras se examina el parámetro, pero el resultado nunca se calculó ni se descartó. Dado que nullpuede representar cualquier clase y que espera que no se invoque el método simulado, ¿no podrían las firmas isA( ... )y any( ... )simplemente regresar en nulllugar de un parámetro genérico * <T>?

De todas formas:

public static <T> T isA(java.lang.Class<T> clazz)

public static <T> T any(java.lang.Class<T> clazz)

La documentación de la API no da ninguna pista sobre esto. También parece decir que la necesidad de tal comportamiento de "no llamar método" es "muy rara". Personalmente, uso esta técnica todo el tiempo : normalmente encuentro que las burlas implican unas pocas líneas que "preparan la escena" ... seguido de un método que luego "reproduce" la escena en el contexto simulado que has puesto en escena ... .y mientras está configurando el escenario y los accesorios, lo último que desea es que los actores entren al escenario a la izquierda y comiencen a actuar con el corazón ...

Pero esto está más allá de mi calificación salarial ... Invito a explicaciones de cualquier sumo sacerdote Mockito que pase ...

* ¿es "parámetro genérico" el término correcto?

Otro escenario posible que puede causar problemas con los espías es cuando está probando frijoles de primavera (con el marco de prueba de primavera) o algún otro marco que está proxing sus objetos durante la prueba .

Ejemplo

@Autowired
private MonitoringDocumentsRepository repository

void test(){
    repository = Mockito.spy(repository)
    Mockito.doReturn(docs1, docs2)
            .when(repository).findMonitoringDocuments(Mockito.nullable(MonitoringDocumentSearchRequest.class));
}

En el código anterior, Spring y Mockito intentarán representar su objeto MonitoringDocumentsRepository, pero Spring será el primero, lo que provocará una llamada real del método findMonitoringDocuments. Si depuramos nuestro código justo después de poner un espía en el objeto del repositorio, se verá así dentro del depurador:

repository = MonitoringDocumentsRepository$$EnhancerBySpringCGLIB$$MockitoMock$

@SpyBean al rescate

Si, en cambio @Autowired, usamos la @SpyBeananotación, resolveremos el problema anterior, la anotación SpyBean también inyectará un objeto de repositorio, pero Mockito lo representará primero y se verá así dentro del depurador

repository = MonitoringDocumentsRepository$$MockitoMock$$EnhancerBySpringCGLIB$

y aquí está el código:

@SpyBean
private MonitoringDocumentsRepository repository

void test(){
    Mockito.doReturn(docs1, docs2)
            .when(repository).findMonitoringDocuments(Mockito.nullable(MonitoringDocumentSearchRequest.class));
}

He encontrado otra razón para que el espía llame al método original.

Alguien tuvo la idea de burlarse de una finalclase y descubrió lo siguiente MockMaker:

Como esto funciona de manera diferente a nuestro mecanismo actual y este tiene limitaciones diferentes y deseamos reunir experiencia y comentarios de los usuarios, esta característica tuvo que activarse explícitamente para estar disponible; Se puede hacer a través del mecanismo de extensión mockito creando el archivo que src/test/resources/mockito-extensions/org.mockito.plugins.MockMakercontiene una sola línea:mock-maker-inline

Fuente: https://github.com/mockito/mockito/wiki/What%27s-new-in-Mockito-2#mock-the-unmockable-opt-in-mocking-of-final-classesmethods

Después de fusionarme y traer ese archivo a mi máquina, mis pruebas fallaron.

Simplemente tuve que eliminar la línea (o el archivo) y spy()trabajé.

Llegué un poco tarde a la fiesta, pero las soluciones anteriores no me funcionaron, así que compartir mi 0.02

Versión de Mokcito: 1.10.19

MyClass.java

private int handleAction(List<String> argList, String action)

Test.java

MyClass spy = PowerMockito.spy(new MyClass());

Lo siguiente NO funcionó para mí (se estaba llamando al método real):

1)

doReturn(0).when(spy , "handleAction", ListUtils.EMPTY_LIST, new String());

2)

doReturn(0).when(spy , "handleAction", any(), anyString());

3)

doReturn(0).when(spy , "handleAction", null, null);

Siguiendo TRABAJADO:

doReturn(0).when(spy , "handleAction", any(List.class), anyString());

Una forma de asegurarse de que no se llame a un método de una clase es anular el método con un ficticio.

    WebFormCreatorActivity activity = spy(new WebFormCreatorActivity(clientFactory) {//spy(new WebFormCreatorActivity(clientFactory));
            @Override
            public void select(TreeItem i) {
                log.debug("SELECT");
            };
        });

Respuesta para usuarios de scala: ¡Incluso poner doReturnprimero no funciona! Ver este post .