mockito
Mockito Best Practices

Style BDDMockito

Le style de test du développement piloté par le comportement (BDD) s'articule autour des étapes "données", "quand" et "alors" des tests. Cependant, le Mockito classique utilise le mot "quand" pour la phase "donnée" et n'inclut pas d'autres constructions en langage naturel pouvant englober le BDD. Ainsi, les alias BDDMockito ont été introduits dans la version 1.8.0 afin de faciliter les tests basés sur le comportement.

La situation la plus courante consiste à supprimer les retours d'une méthode. Dans l'exemple suivant, la getStudent(String) du StudentRepository renverra new Student(givenName, givenScore) si elle est invoquée avec un argument égal à 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);
    }
}

Parfois, il est souhaitable de vérifier si l'exception renvoyée par la dépendance est correctement gérée ou retransmise dans une méthode testée. Un tel comportement peut être écrasé en phase "donnée" de cette manière:

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

Parfois, il est souhaitable de mettre en place certains effets secondaires qu’une méthode de compression devrait introduire. Surtout, il peut être utile lorsque:

• la méthode stubbed est une méthode supposée modifier l'état interne d'un objet passé

• la méthode stubbed est une méthode vide

Un tel comportement peut être écrasé en phase "donnée" avec une "réponse":

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

Lorsque l'on souhaite vérifier les interactions avec un simulacre, on peut le faire en phase "alors" avec les méthodes should() ou should(VerificationMode) (uniquement depuis 1.10.5):

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

Lorsque l'on veut vérifier qu'il n'y a plus d'interactions avec un simulacre déjà vérifié, cela peut se faire en phase "alors" avec shouldHaveNoMoreInteractions() (depuis 2.0.0):

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

Lorsque l'on souhaite vérifier qu'il n'y avait absolument aucune interaction avec un simulacre, on peut le faire dans la phase "then" avec shouldHaveNoMoreInteractions() (depuis 2.0.0):

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

Lorsque l'on souhaite vérifier si les méthodes ont été invoquées dans l'ordre, il est possible d'effectuer la phase "then" avec should(InOrder) (depuis 1.10.5) et should(InOrder, VerificationMode) (depuis 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