Avanceret test med Mockito

1.1 Mockito bibliotek

I dag vil vi stifte bekendtskab med avanceret test. Mere specifikt med Mockito -biblioteket . Tænk ikke engang på at komme ud af denne forretning.

For det første er dette bibliotek en standard i Spring- testning . Hvilket faktisk er standarden i Java-backend-udviklingsindustrien.

For det andet skal du skrive test til din Spring-kode . Den eneste måde at forstå, at den backend, du skrev, fungerer, som den skal, er at kalde metoder for dens API . Og at gøre det med test er 10 gange nemmere end uden dem. Du vil selv se.

Du kan tilføje Mockito-biblioteket til dit pom.xmlved hjælp af koden:

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

Hele kildekoden til Mockito-projektet kan findes på GitHub .

1.2 Spotobjekter

Så hvad er denne Mockito, og hvorfor er den så god?

I processen med udvikling og udvikling af test var der meget ofte behov for at smutte en form for "stubbe" ind i koden i stedet for et rigtigt objekt.

Eksempelvis bliver koden, der fungerer med databasen, testet og ændrer noget der. Det er godt, at denne databases tilstand er den samme før hver test (ellers vil testene være anderledes). Og jeg vil gerne have, at basen er enklere for hurtigt at rulle disse tilstande tilbage.

Eller du tester for eksempel en kode, der sender nyttige SMS'er. Og til direkte mails bruger han en slags betalt SMS Gateway. Det ville være rart at smide en eller anden virtuel Gateway ind i den for at teste koden, for ikke at sende hundredvis af SMS'er til uforståelige mennesker.

Eller din kode anmoder om data fra andre webservere, der simpelthen ikke er tilgængelige på testserveren. Eller du skriver en kode til onlinebetalinger, som skal testes 50 gange, og først derefter må bruges i rigtige finansielle kanaler.

Jeg tror du forstår ... Virtuelle objekter, eller som de også kaldes stubobjekter, er en meget nyttig ting.

Og her kommer vanskeligheden - Java har statisk skrivning. Det betyder, at for at ReadDatabasetildele en reference til et objekt til en variabel i stedet for et objekt af typen VirtualDatabase, skal du arve klassen VirtualDatabasefra RealDatabase.

Så viser det sig, at klassen har RealDatabaseen masse private metoder og variabler, der gemmer referencer til andre rigtige objekter, og du kan ikke skrive en normal stub på denne måde. I teorien er det godt, men i praksis er det en blindgyde.

Og her kommer til undsætning ( du kan læseDynamicProxy mere detaljeret ), som dukkede op tilbage i Java 5. Det giver dig mulighed for at oprette virtuelle objekter, som compileren ikke har nogen klager over.

Sådanne virtuelle objekter kaldes mocks (fra ordet mock - layout). Mockito-biblioteket var i stand til at tage arbejdet med disse håner til en hidtil uset højde. Deraf i øvrigt navnet på biblioteket.

1.3 @ExtendWith annotation

Mockito-biblioteket fungerer godt med JUnit, det kan endda betragtes som en udvidelse af det.

Der er to måder at aktivere Mockito-biblioteket i dine enhedstests. Den første måde er at tilføje en speciel anmærkning:

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

Den anden måde er at aktivere dens arbejde ved at kalde metoden openMocks():

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

Oftest vil du se den første mulighed, men nogle gange er det nyttigt at vide, at der er en anden.