mockito
Mejores Prácticas de Mockito

Estilo BDDMockito

El estilo de prueba de desarrollo conducido por comportamiento (BDD) gira en torno a las etapas "dado", "cuándo" y "luego" en las pruebas. Sin embargo, Mockito clásico usa la fase "cuándo" palabra para "dada", y no incluye otras construcciones de lenguaje natural que puedan abarcar el BDD. Por lo tanto, los alias de BDDMockito se introdujeron en la versión 1.8.0 para facilitar las pruebas basadas en el comportamiento.

La situación más común es apilar los retornos de un método. En el siguiente ejemplo, el getStudent(String) del StudentRepository new Student(givenName, givenScore) devolverá new Student(givenName, givenScore) si se invoca con un argumento que es igual a givenName .

import static org.mockito.BDDMockito.*;

public class ScoreServiceTest {

    private StudentRepository studentRepository = mock(StudentRepository.class);

    private ScoreService objectUnderTest = new ScoreService(studentRepository);

    @Test
    public void shouldCalculateAndReturnScore() throws Exception {
        //given
        String givenName = "Johnny";
        int givenScore = 10;
        given(studentRepository.getStudent(givenName))
            .willReturn(new Student(givenName, givenScore));

        //when
        String actualScore = objectUnderTest.calculateStudentScore(givenName);

        //then
        assertEquals(givenScore, actualScore);
    }
}

A veces, se desea verificar si la excepción generada por la dependencia se maneja correctamente o se vuelve a derribar en un método bajo prueba. Tal comportamiento puede ser tachado en la fase "dada" de esta manera:

willThrow(new RuntimeException())).given(mock).getData();

A veces se desea establecer algunos efectos secundarios que debe introducir un método de rechazo. Especialmente puede ser útil cuando:

• El método de código auxiliar es un método que se supone que cambia el estado interno de un objeto pasado.

• El método de código es un método vacío.

Dicho comportamiento puede ser tachado en la fase "dada" con una "Respuesta":

willAnswer(invocation -> this.prepareData(invocation.getArguments()[0])).given(mock).processData();

Cuando se desea verificar las interacciones con un simulacro, se puede hacer en la "fase" y luego con should() o should(VerificationMode) (solo desde 1.10.5) métodos:

then(mock).should().getData(); // verifies that getData() was called once
then(mock).should(times(2)).processData(); // verifies that processData() was called twice

Cuando se desea verificar que no hubo más interacciones con un simulacro además del verificado, se puede hacer en la fase "entonces" con shouldHaveNoMoreInteractions() (desde 2.0.0):

then(mock).shouldHaveNoMoreInteractions(); // analogue of verifyNoMoreInteractions(mock) in classical Mockito

Cuando se desea verificar que no hubo absolutamente ninguna interacción con un simulacro, se puede hacer en la fase "entonces" con shouldHaveNoMoreInteractions() (desde 2.0.0):

then(mock).shouldHaveZeroInteractions(); // analogue of verifyZeroInteractions(mock) in classical Mockito

Cuando se desea verificar si los métodos se invocaron en orden, se puede hacer en la fase "entonces" con should(InOrder) (desde 1.10.5) y should(InOrder, VerificationMode) (desde 2.0.0):

InOrder inOrder = inOrder(mock);

// test body here

then(mock).should(inOrder).getData(); // the first invocation on the mock should be getData() invocation
then(mock).should(inOrder, times(2)).processData(); // the second and third invocations on the mock should be processData() invocations