Geavanceerd testen met Mockito

1.1 Mockito-bibliotheek

Vandaag maken we kennis met geavanceerd testen. Meer specifiek, met de Mockito- bibliotheek . Denk er niet eens aan om uit deze business te stappen.

Ten eerste is deze bibliotheek een standaard in Spring- testen . Wat eigenlijk de standaard is in de Java-backend-ontwikkelingsindustrie.

Ten tweede moet u tests schrijven voor uw Spring-code . De enige manier om te begrijpen dat de backend die je hebt geschreven werkt zoals het hoort, is door methodes van zijn API aan te roepen . En het doen met tests is 10 keer gemakkelijker dan zonder hen. Je zult het zelf zien.

U kunt de Mockito-bibliotheek aan de uwe toevoegen pom.xmlmet behulp van de code:

<dependency>
    <groupId>org.mockito</groupId>
    <artifactId>mockito-junit-jupiter</artifactId>
    <version>4.2.0</version>
    <scope>test</scope>
</dependency>

De volledige broncode voor het Mockito-project is te vinden op GitHub .

1.2 Nepobjecten

Dus wat is deze Mockito en waarom is hij zo goed?

Tijdens het ontwikkelingsproces en de ontwikkeling van testen was het heel vaak nodig om een ​​soort "stub" in de code te stoppen in plaats van een echt object.

Zo wordt de code die werkt met de database getest en verandert daar iets. Het is goed dat voor elke test de status van deze database hetzelfde is (anders zijn de tests anders). En ik zou graag willen dat de basis eenvoudiger is om deze toestanden snel terug te draaien.

Of je test bijvoorbeeld een code die handige sms'jes verstuurt. En voor direct mailings gebruikt hij een soort betaalde sms-gateway. Het zou leuk zijn om er een virtuele gateway in te stoppen om de code te testen, om niet honderden sms'jes naar onbegrijpelijke mensen te sturen.

Of uw code vraagt ​​gegevens op van andere webservers die simpelweg niet beschikbaar zijn op de testserver. Of je schrijft een code voor online betalingen die 50 keer moet worden getest en pas daarna mag worden gebruikt in echte financiële kanalen.

Ik denk dat je begrijpt ... Virtuele objecten, of zoals ze ook wel stub-objecten worden genoemd, zijn erg handig.

En hier komt de moeilijkheid - Java heeft statisch typen. Dit betekent dat om ReadDatabaseeen ​​verwijzing naar een object toe te wijzen aan een variabele in plaats van aan een object van het type VirtualDatabase, u de klasse moet erven VirtualDatabasevan RealDatabase.

Dan blijkt dat de klasse RealDatabaseeen heleboel privémethoden en variabelen heeft die verwijzingen naar andere echte objecten opslaan, en je kunt op deze manier geen normale stub schrijven. In theorie is het goed, maar in de praktijk is het een doodlopende weg.

En hier komt te hulp ( je kuntDynamicProxy meer in detail lezen ), die verscheen in Java 5. Hiermee kun je virtuele objecten maken waar de compiler geen klachten over heeft.

Dergelijke virtuele objecten worden mocks genoemd (van het woord mock - lay-out). De Mockito-bibliotheek wist het werk met deze mocks naar een ongekende hoogte te brengen. Vandaar trouwens de naam van de bibliotheek.

1.3 @ExtendWith annotatie

De Mockito-bibliotheek werkt geweldig met JUnit, het kan zelfs als een uitbreiding ervan worden beschouwd.

Er zijn twee manieren om de Mockito-bibliotheek in uw unit-tests in te schakelen. De eerste manier is om een ​​speciale annotatie toe te voegen:

@ExtendWith(MockitoExtension.class)
public class MockitoAnnotationTest {
    ...
}

De tweede manier is om het werk mogelijk te maken door de methode aan te roepen openMocks():

public class MockitoAnnotationTest {
    @BeforeEach
    public void init() {
        MockitoAnnotations.openMocks(this);
   }
}

Meestal zie je de eerste optie, maar soms is het handig om te weten dat er een tweede is.