Cómo burlarse de los métodos nulos con Mockito

¿Cómo burlarse de los métodos con tipo de retorno nulo?

Implementé un patrón de observación, pero no puedo burlarme de él porque no sé cómo.

Y traté de encontrar un ejemplo en Internet pero no tuve éxito.

Mi clase se ve así:

public class World {

    List<Listener> listeners;

    void addListener(Listener item) {
        listeners.add(item);
    }

    void doAction(Action goal,Object obj) {
        setState("i received");
        goal.doAction(obj);
        setState("i finished");
    }

    private string state;
    //setter getter state
} 

public class WorldTest implements Listener {

    @Test public void word{
    World  w= mock(World.class);
    w.addListener(this);
    ...
    ...

    }
}

interface Listener {
    void doAction();
}

El sistema no se activa con simulacro.

Quiero mostrar el estado del sistema mencionado anteriormente. Y hacer afirmaciones según ellos.

Echa un vistazo a los documentos de la API de Mockito . A medida que el documento vinculado menciona (punto # 12), puede utilizar cualquiera de los doThrow(), doAnswer(), doNothing(), doReturn()familia de métodos de marco Mockito para burlarse de los métodos vacíos.

Por ejemplo,

Mockito.doThrow(new Exception()).when(instance).methodName();

o si quieres combinarlo con un comportamiento de seguimiento,

Mockito.doThrow(new Exception()).doNothing().when(instance).methodName();

Suponiendo que está buscando burlarse del setter setState(String s)en la clase World a continuación, el código usa el doAnswermétodo para burlarse del setState.

World  mockWorld = mock(World.class); 
doAnswer(new Answer<Void>() {
    public Void answer(InvocationOnMock invocation) {
      Object[] args = invocation.getArguments();
      System.out.println("called with arguments: " + Arrays.toString(args));
      return null;
    }
}).when(mockWorld).setState(anyString());

Creo que he encontrado una respuesta más simple a esa pregunta, para llamar al método real para un solo método (incluso si tiene un retorno nulo), puede hacer esto:

Mockito.doCallRealMethod().when(<objectInstance>).<method>();
<objectInstance>.<method>();

O bien, puede llamar al método real para todos los métodos de esa clase, haciendo esto:

<Object> <objectInstance> = mock(<Object>.class, Mockito.CALLS_REAL_METHODS);

Además de lo que dijo @sateesh, cuando solo quieres burlarte de un método nulo para evitar que la prueba lo llame, puedes usar un Spymétodo de esta manera:

World world = new World();
World spy = Mockito.spy(world);
Mockito.doNothing().when(spy).methodToMock();

Cuando desee ejecutar su prueba, asegúrese de llamar al método en prueba en el spyobjeto y no en el worldobjeto. Por ejemplo:

assertEquals(0,spy.methodToTestThatShouldReturnZero());

La solución del llamado problema es usar un spy Mockito.spy (...) en lugar de un mock Mockito.mock (..) .

Spy nos permite burlas parciales. Mockito es bueno en este asunto. Debido a que tiene una clase que no está completa, de esta manera se burla de algún lugar requerido en esta clase.

En primer lugar: siempre debe importar mockito static, de esta manera el código será mucho más legible (e intuitivo):

import static org.mockito.Mockito.*;

Para burlarse parcial y aún mantener la funcionalidad original en el resto, mockito ofrece "Spy".

Puede usarlo de la siguiente manera:

private World world = spy(World.class);

Para eliminar la ejecución de un método, puede usar algo como esto:

doNothing().when(someObject).someMethod(anyObject());

para dar un comportamiento personalizado a un método, use "when" con un "thenReturn":

doReturn("something").when(this.world).someMethod(anyObject());

Para obtener más ejemplos, encuentre las excelentes muestras de mockito en el documento.

Cómo burlarse de los métodos nulos con mockito: hay dos opciones:

1. doAnswer - Si queremos que nuestro método vacío simulado haga algo (burlarse del comportamiento a pesar de estar vacío).
2. doThrow- Luego está Mockito.doThrow()si quieres lanzar una excepción del método de anulación simulada.

El siguiente es un ejemplo de cómo usarlo (no es un caso de uso ideal pero solo quería ilustrar el uso básico).

@Test
public void testUpdate() {

    doAnswer(new Answer<Void>() {

        @Override
        public Void answer(InvocationOnMock invocation) throws Throwable {
            Object[] arguments = invocation.getArguments();
            if (arguments != null && arguments.length > 1 && arguments[0] != null && arguments[1] != null) {

                Customer customer = (Customer) arguments[0];
                String email = (String) arguments[1];
                customer.setEmail(email);

            }
            return null;
        }
    }).when(daoMock).updateEmail(any(Customer.class), any(String.class));

    // calling the method under test
    Customer customer = service.changeEmail("old@test.com", "new@test.com");

    //some asserts
    assertThat(customer, is(notNullValue()));
    assertThat(customer.getEmail(), is(equalTo("new@test.com")));

}

@Test(expected = RuntimeException.class)
public void testUpdate_throwsException() {

    doThrow(RuntimeException.class).when(daoMock).updateEmail(any(Customer.class), any(String.class));

    // calling the method under test
    Customer customer = service.changeEmail("old@test.com", "new@test.com");

}
}

Puede encontrar más detalles sobre cómo burlarse y probar métodos vacíos con Mockito en mi publicación Cómo burlarse de Mockito (Una guía completa con ejemplos)

Agregar otra respuesta al grupo (sin juego de palabras) ...

Debe llamar al método doAnswer si no puede \ no quiere usar espías. Sin embargo, no necesariamente necesita lanzar su propia respuesta . Hay varias implementaciones predeterminadas. En particular, CallsRealMethods .

En la práctica, se parece a esto:

doAnswer(new CallsRealMethods()).when(mock)
        .voidMethod(any(SomeParamClass.class));

O:

doAnswer(Answers.CALLS_REAL_METHODS.get()).when(mock)
        .voidMethod(any(SomeParamClass.class));

En Java 8, esto se puede hacer un poco más limpio, suponiendo que tenga una importación estática para org.mockito.Mockito.doAnswer:

doAnswer(i -> {
  // Do stuff with i.getArguments() here
  return null;
}).when(*mock*).*method*(*methodArguments*);

Esto return null;es importante y sin él la compilación fallará con algunos errores bastante oscuros, ya que no podrá encontrar una anulación adecuada paradoAnswer .

Por ejemplo, un ExecutorServiceque solo ejecuta inmediatamente cualquier Runnablepase que se execute()pueda implementar usando:

doAnswer(i -> {
  ((Runnable) i.getArguments()[0]).run();
  return null;
}).when(executor).execute(any());

Creo que sus problemas se deben a su estructura de prueba. Me resulta difícil mezclar burlas con el método tradicional de implementación de interfaces en la clase de prueba (como lo ha hecho aquí).

Si implementa el oyente como un simulacro, puede verificar la interacción.

Listener listener = mock(Listener.class);
w.addListener(listener);
world.doAction(..);
verify(listener).doAction();

Esto debería satisfacerte de que el 'Mundo' está haciendo lo correcto.

Usando Mockito.doThrow como en:

Mockito.doThrow(new Exception()).when(instance).methodName();

puedes probar este buen ejemplo:

public void testCloseStreamOnException() throws Exception {
    OutputStream outputStream = Mockito.mock(OutputStream.class);
    IFileOutputStream ifos = new IFileOutputStream(outputStream);
    Mockito.doThrow(new IOException("Dummy Exception")).when(outputStream).flush();
    try {
      ifos.close();
      fail("IOException is not thrown");
    } catch (IOException ioe) {
      assertEquals("Dummy Exception", ioe.getMessage());
    }
    Mockito.verify(outputStream).close();
  }

Fuente: http://apisonar.com/java-examples/org.mockito.Mockito.doThrow.html#Example-19