Avancerad testning med Mockito

1.1 Mockito-bibliotek

Idag ska vi bekanta oss med avancerad testning. Mer specifikt med Mockito -biblioteket . Tänk inte ens på att ta dig ur den här affären.

För det första är det här biblioteket en standard i vårtestning . Vilket faktiskt är standarden inom Java-backend-utvecklingsbranschen.

För det andra måste du skriva tester för din Spring-kod . Det enda sättet att förstå att backend du skrev fungerar som den ska är att anropa metoder för dess API . Och att göra det med tester är 10 gånger lättare än utan dem. Du kommer att se själv.

Du kan lägga till Mockito-biblioteket till ditt pom.xmlmed koden:

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

Hela källkoden för Mockito-projektet finns på GitHub .

1.2 Spotobjekt

Så vad är denna Mockito och varför är den så bra?

Under utvecklingen och utvecklingen av testning fanns det ofta ett behov av att släpa in någon form av "stubb" i koden istället för ett riktigt objekt.

Till exempel testas koden som fungerar med databasen och ändrar något där. Det är bra att tillståndet för denna databas är detsamma före varje test (annars kommer testerna att vara olika). Och jag skulle vilja att basen skulle vara enklare för att snabbt kunna rulla tillbaka dessa tillstånd.

Eller så testar du till exempel en kod som skickar användbara SMS. Och för direktutskick använder han någon form av betald SMS-gateway. Det skulle vara trevligt att lägga in någon virtuell Gateway i den för att testa koden, för att inte skicka hundratals SMS till oförstående människor.

Eller så begär din kod data från andra webbservrar som helt enkelt inte är tillgängliga på testservern. Eller så skriver du en kod för onlinebetalningar som måste testas 50 gånger, och först därefter tillåtas användas i riktiga finansiella kanaler.

Jag tror du förstår ... Virtuella objekt, eller som de också kallas stubbobjekt, är en väldigt användbar sak.

Och här kommer svårigheten - Java har statisk skrivning. Det betyder att för att ReadDatabasetilldela en referens till ett objekt till en variabel istället för ett objekt av typen VirtualDatabasemåste du ärva klassen VirtualDatabasefrån RealDatabase.

Sedan visar det sig att klassen har RealDatabaseett gäng privata metoder och variabler som lagrar referenser till andra verkliga objekt, och du kan inte skriva en normal stubb på det här sättet. I teorin är det bra, men i praktiken är det en återvändsgränd.

Och här kommer till räddningen ( du kan läsaDynamicProxy mer detaljerat ), som dök upp i Java 5. Det låter dig skapa virtuella objekt som kompilatorn inte har några klagomål på.

Sådana virtuella objekt kallas mocks (från ordet mock - layout). Mockito-biblioteket kunde ta arbetet med dessa hånar till en aldrig tidigare skådad höjd. Därav förresten bibliotekets namn.

1.3 @ExtendWith anteckning

Mockito-biblioteket fungerar utmärkt med JUnit, det kan till och med betraktas som en förlängning av det.

Det finns två sätt att aktivera Mockito-biblioteket i dina enhetstester. Det första sättet är att lägga till en speciell kommentar:

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

Det andra sättet är att aktivera dess arbete genom att anropa metoden openMocks():

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

Oftast ser du det första alternativet, men ibland är det användbart att veta att det finns ett andra.