mockito
Mockito Best Practices

BDDMockito-stijl

Gedragsgedreven ontwikkeling (BDD) -teststijl draait om 'gegeven', 'wanneer' en 'dan' fasen in tests. Klassieke Mockito gebruikt echter de "wanneer" woord voor "gegeven" fase en bevat geen andere natuurlijke taalconstructies die BDD kunnen omvatten. Zo werden BDDMockito- aliassen geïntroduceerd in versie 1.8.0 om gedragsgestuurde tests te vergemakkelijken.

De meest voorkomende situatie is het terugsturen van een methode. In het volgende voorbeeld getStudent(String) methode getStudent(String) van de StudentRepository een new Student(givenName, givenScore) als deze wordt aangeroepen met een argument dat gelijk is aan 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);
    }
}

Soms is het wenselijk om te controleren of een uitzondering die wordt veroorzaakt door afhankelijkheid correct wordt afgehandeld of opnieuw wordt gegooid in een testmethode. Dergelijk gedrag kan op deze manier in de "gegeven" fase worden gestopt:

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

Soms is het gewenst om enkele bijwerkingen op te zetten die een koppige methode zou moeten introduceren. Vooral het kan van pas komen wanneer:

• de stubbed-methode is een methode waarvan wordt aangenomen dat deze de interne status van een doorgegeven object verandert

• de stubbed-methode is een nietige methode

Dergelijk gedrag kan in de "gegeven" fase worden gestopt met een "Antwoord":

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

Wanneer het gewenst is om interacties met een mock te verifiëren, kan dit worden gedaan in de "dan" fase met should() of should(VerificationMode) (alleen sinds 1.10.5) methoden:

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

Wanneer het gewenst is om te verifiëren dat er geen interacties meer waren met een mock naast al geverifieerd, kan dit worden gedaan in de "dan" -fase met shouldHaveNoMoreInteractions() (sinds 2.0.0):

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

Wanneer het gewenst is om te verifiëren dat er absoluut geen interacties met een mock waren, kan dit in de "dan" -fase worden gedaan met shouldHaveNoMoreInteractions() (sinds 2.0.0):

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

Wanneer het gewenst is om te controleren of methoden zijn aangeroepen , kan dit in de "dan" -fase worden gedaan met should(InOrder) (sinds 1.10.5) en should(InOrder, VerificationMode) (sinds 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