Avansert testing med Mockito

1.1 Mockito-bibliotek

I dag skal vi bli kjent med avansert testing. Mer spesifikt, med Mockito -biblioteket . Ikke engang tenk på å komme deg ut av denne bransjen.

For det første er dette biblioteket en standard i Spring- testing . Som faktisk er standarden i Java-backend-utviklingsindustrien.

For det andre må du skrive tester for Spring-koden din . Den eneste måten å forstå at backend-en du skrev fungerer som den skal, er å kalle metoder for API-en . Og å gjøre det med tester er 10 ganger enklere enn uten dem. Du vil se selv.

Du kan legge til Mockito-biblioteket til ditt pom.xmlved å bruke koden:

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

Hele kildekoden for Mockito-prosjektet finner du på GitHub .

1.2 Håneobjekter

Så hva er denne Mockito og hvorfor er den så bra?

I prosessen med utvikling og utvikling av testing var det ofte behov for å skli en slags "stubb" inn i koden i stedet for et ekte objekt.

For eksempel blir koden som fungerer med databasen testet og endrer noe der. Det er bra at før hver test er tilstanden til denne databasen den samme (ellers vil testene være forskjellige). Og jeg vil gjerne at basen skal være enklere for raskt å rulle tilbake disse tilstandene.

Eller du tester for eksempel en kode som sender nyttig SMS. Og for direkte utsendelser bruker han en slags betalt SMS-gateway. Det ville vært fint å legge en virtuell Gateway inn i den for å teste koden, for ikke å sende hundrevis av SMS til uforståelige mennesker.

Eller koden din ber om data fra andre webservere som rett og slett ikke er tilgjengelige på testserveren. Eller du skriver en kode for nettbetalinger som må testes 50 ganger, og først da tillates brukt i ekte finansielle kanaler.

Jeg tror du forstår ... Virtuelle objekter, eller som de også kalles stubbeobjekter, er en veldig nyttig ting.

Og her kommer vanskeligheten - Java har statisk skriving. Dette betyr at for å ReadDatabasetilordne en referanse til et objekt til en variabel i stedet for et objekt av typen VirtualDatabase, må du arve klassen VirtualDatabasefra RealDatabase.

Så viser det seg at klassen har RealDatabaseen haug med private metoder og variabler som lagrer referanser til andre virkelige objekter, og du kan ikke skrive en normal stubb på denne måten. I teorien er det bra, men i praksis er det en blindvei.

Og her kommer til unnsetning ( du kan leseDynamicProxy mer detaljert ), som dukket opp tilbake i Java 5. Den lar deg lage virtuelle objekter som kompilatoren ikke har noen klager på.

Slike virtuelle objekter kalles mocks (fra ordet mock - layout). Mockito-biblioteket var i stand til å ta arbeidet med disse spottene til en enestående høyde. Derav, forresten, navnet på biblioteket.

1.3 @ExtendWith merknad

Mockito-biblioteket fungerer utmerket med JUnit, det kan til og med betraktes som en utvidelse av det.

Det er to måter å aktivere Mockito-biblioteket i enhetstestene dine. Den første måten er å legge til en spesiell merknad:

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

Den andre måten er å aktivere arbeidet ved å kalle metoden openMocks():

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

Oftest vil du se det første alternativet, men noen ganger er det nyttig å vite at det er et andre.