Meny

Mockito Tutorial: Mockito Framework for Mocking in Unit Testing

  • Huvud
  • Övrig
  • Mockito Tutorial: Mockito Framework for Mocking in Unit Testing

mockito tutorial mockito framework

Prova Vårt Instrument För Att Eliminera Problem

En komplett guide till Mockito Framework: Praktiska Mockito-handledning

programvara som är installerad på en dator och används för att hantera virtuella maskiner

Enhetstestning är en enkel men ändå effektiv teknik för att få en bra nivå av förtroende för koden som ska skickas.

Dessutom undviks regressionsproblem med varje kodkod som checkas in.

Med mikrotjänster av arkitektur (och även för enkel struktur med grundläggande databassamtal) räcker inte enkel enhetstestning. Vad vi behöver är att håna beroenden och testa den faktiska logiken för metoden som testas.

Mockito handledning

Lista över ALLA Mockito-självstudier i denna serie:

Handledning nr 1: Mockito Framework för Mocking i Unit Testing (Denna handledning)
Handledning nr 2: Skapa Mocks and Spies i Mockito
Handledning nr 3: Olika typer av matchare från Mockito
Handledning nr 4: Hånar privata, statiska och ogiltiga metoder med Mockito
Handledning nr 5: Topp 12 Mockito intervjufrågor

************************************************* * *******************

Översikt över handledningar i denna Mockito-serie

Handledning #Vad du kommer att lära dig
Handledning nr 1: Mockito Framework för Mocking i Unit Testing

Lär dig hån med Mockito - En omfattande Mockito-handledning för nybörjare med kodexempel. Lär dig Mocking Framework för Mocking i Unit Testing.
Handledning nr 2: Skapa Mocks and Spies i Mockito

Mocks and Spies är typer av testdubblar, vilket är till hjälp för att skriva enhetstester. Båda förklaras i denna Mockito Spy-handledning med kodexempel.
Handledning nr 3: Olika typer av matchare från Mockito

Lär dig hur du använder olika typer av matchare från Mockito. Matchare är som jokertecken där du istället för en specifik ingång / utgång anger ett intervall för inmatning. Argument och verifiering är de två typerna av Matchers i Mockito som förklaras i detalj här.
Handledning nr 4: Hånar privata, statiska och ogiltiga metoder med Mockito

Lär dig att spotta privata, statiska och ogiltiga metoder i Mockito med exempel. Lär dig att spotta privata och statiska metoder genom att testa ramverket för enhet PowerMockito.
Handledning nr 5: Topp 12 Mockito intervjufrågor

Mockito intervju Frågor och svar med exempelkodsexempel. Detta hjälper dig att knäcka alla Mockito Mocking Framework-intervjuer framgångsrikt.

Låt oss börja med den första guiden i denna serie !!

Vad du kommer att lära dig:

Hånfull i enhetstestning

Mocks / Stubs är en term som människor ofta hör när man skapar enhetstester i synnerhet.

Så vad är egentligen Mocking? Enkelt uttryckt är det ingenting annat än att tillhandahålla en kontrollerad instans eller implementering av beroende som koden som testas beror på för att testa dess kärnlogik.

Anledningen till att jag nämnde det som en kontrollerad instans är att beroendets beteende kan programmeras eller kontrolleras som önskat för metoden eller systemet som testas.

För att förklara det schematiskt, låt oss ta ett exempel på alla affärs- eller e-handelsapplikationer. Nästan alla sådana applikationer har i första hand tre lager, dvs. Användargränssnitt, Business Layer & Data Access-lager (som pratar med det underliggande datalagret)

Exempel: Beroende på enhetstest

Med hänvisning till ovanstående diagram har Business Layer tre beroenden, dvs. Data Access Layer och 2 andra tjänster som är Service 1 och Service 2.

Titta på det på det här sättet - En app som Google Maps kan ha beroende av en

  1. Faktiska datalager som MySQL eller någon annan ingen SQL-databas som lagrar kartdata.
  2. En extern tjänst som CoordinateService som tillhandahåller latitud och longitud för en plats.
  3. En extern tjänst som trafiktjänst som ger trafikinformation i realtid för ett givet koordinatpar.

Så om någon försöker validera kärnverksamhetslogiken med enhetstest, tills och om de inte har fungerande implementeringar av dessa beroenden, kunde testerna inte köras.

Hånar kommer till räddning i dessa situationer, oavsett om ditt beroende är igång eller inte, är du alltid garanterad att köra din affärslogik med ett programmerat svar för beroendet som ringer från koden som testas.

Typer / kategorier av testdubblar

Mock är i grunden en typ av 'Test Double' - det är ett tekniskt jargong. 'Test Double' betyder i huvudsak ett objekt som ersätts av motsvarande verklig objektinstans eller beroende.

Det finns olika typer av testdubblar som nämns nedan:

# 1) Förfalskningar:

En falsk är en fungerande implementering som liknar ett verkligt beroende, förutom att det är lokalt för systemet som testas.

Exempel: Istället för att träffa en riktig produktions-DB använder testet en enkel insamling / i-minne för att lagra data.

Typ av testdubblar - förfalskningar

# 2) Stubbar:

Stubbar är förkonfigurerade svar när ett beroende anropas från systemet som testas.

Typ av testdubblar - Stubbar

# 3) Spioner:

Som namnet antyder är det faktiskt det verkliga funktionssamtalet (beroende) med någon bevakningsmekanism. Lägg upp samtalet, det kan verifieras om samtalet faktiskt utlöstes eller inte tillsammans med parametrarna.

Typ av testdubblar - Spioner

# 4) Hånar:

Mocks är speciella förekomster av objekt där Stubbed / förkonfigurerade svar kan specificeras. Det faktum att mocken ringde kan verifieras som ett påstående i testet.

Till exempel:

Det finns en rapportgeneratorfunktion som skickar ett e-postmeddelande till en angiven adress under körningen.

Eftersom vi inte vill skicka faktiskt e-postmeddelande, om och om igen, under testningen, bespottas EmailService (och e-postmetoden som skickar e-postmeddelandet är konfigurerad att göra ingenting när det kallas). I slutet av testet kan vi bara verifiera att e-posttjänstens e-posttjänst har ringts upp genom det hånade objektet.

Olika spottande ramar

Nästan alla språk erbjuder olika typer av hånfulla ramar. Vi kommer att skriva en provkod med Mockito som är en öppen källkod Mocking-ramverk för Java.

Anatomi av ett enkelt enhetstest med hånat beroende. Antag att vi försöker enhetstesta en applikation som beräknar totala poäng för en student i alla ämnen och skriver den till DB.

public void calculateSumAndStore(String studentId, int() scores) { int total = 0; for (int score: scores) { total = total + score; } // write total to DB databaseImpl.updateScores(studentId, total); }

Om vi ​​nu vill skriva ett enhetstest för metoden - beräknaSumAndStore, kanske vi inte har en verklig implementering av en databas för att lagra summan. I så fall kommer vi aldrig att kunna testa den här funktionen.

Men med mocks på plats kan vi helt enkelt skicka en Mock for database-tjänst och validera resten av logiken

Provtest enligt nedan:

@Test public void calculateSumAndStore_withValidInput_shouldCalculateAndUpdateResultInDb() { // Arrange studentScores = new StudentScoreUpdates(mockDatabase); int() scores = { 60, 70, 90 }; Mockito.doNothing().when(mockDatabase).updateScores('student1', 220); // Act studentScores.calculateSumAndStore('student1', scores); // Assert Mockito.verify(mockDatabase, Mockito.times(1)).updateScores('student1', 220); }

Vi har sett i ovanstående test, vi har tillhandahållit ett mockDatabase-objekt till föräldraklassen (för metoden som testas) och vi har ställt in ett stub-svar för mockedDatabase-objektet - rad # 6 ovan (Mockito.doNothing (). When (mockDatabase) .updateScores (“student1”, 220);)

De viktiga punkterna att notera från ovan är:

# 1) Det hånade objektet måste ställa in stubbed-svar för alla metoder som kommer att anropas under körningen av funktionen.

#två) Parametrarna som anges under skapandet av stubbar kan vara specifika eller generiska.

Exempel i ovanstående fall - vi har angett parametrarna för updateScores-metoden som 'student1' och 220 eftersom vi vet att det här är de exakta ingångarna som vår metod kommer att kallas till.

# 3) Under verifieringen validerar vi följande:

  • metoden mockDatabase.updateScores anropades.
  • Argumenten var ”student1” respektive 220.
  • Metoden updateScores kallades en gång.

Låt oss nu prova att ändra testkoden lite och se vad som händer:

Jag kommer att ändra argumentet i mock-installationen från 'student1' till anyString (Mockito tillhandahåller en standardmatcher med namnet anyString ()) & 220 till anyInteger (Mockito tillhandahåller en standardmatcher med namnet anyInt () och den matchar alla heltal)

@Test public void calculateSumAndStore_withValidInput_shouldCalculateAndUpdateResultInDb() { // Arrange studentScores = new StudentScoreUpdates(mockDatabase); int() scores = { 60, 70, 90 }; Mockito.doNothing().when(mockDatabase).updateScores(anyString(), anyInt()); // Act studentScores.calculateSumAndStore('student1', scores); // Assert Mockito.verify(mockDatabase, Mockito.times(1)).updateScores('student1', 220); }

Försök att köra testet igen och testet ska fortfarande vara grönt.

(Låt oss nu ändra verifieringen / påståendena och ändra något av argumenten.

Låt oss ändra 220 till 230. Nu är förväntningen att testet ska misslyckas eftersom detta inte är det förväntade argumentet som databaseUpdate måste ha anropats med.

@Test public void calculateSumAndStore_withValidInput_shouldCalculateAndUpdateResultInDb() { // Arrange studentScores = new StudentScoreUpdates(mockDatabase); int() scores = { 60, 70, 90 }; Mockito.doNothing().when(mockDatabase).updateScores(anyString(), anyInt()); // Act studentScores.calculateSumAndStore('student1', scores); // Assert Mockito.verify(mockDatabase, Mockito.times(1)).updateScores('student1', 230); }

Efter att ha kört testet, hänvisa till felloggarna som visas nedan (det nämns tydligt att de faktiska argumenten inte matchade de förväntade).

Argumenten är olika! Ville ha:
mockDatabase.updateScores (“student1”, 230);
-> på com.mocking.sampleMocks.StudentScoreUpdatesUnitTests.calculateSumAndStore_withValidInput_shouldCalculateAndUpdateResultInDb (StudentScoreUpdatesUnitTests.java:37)

Verklig åberopande har olika argument:
mockDatabase.updateScores (“student1”, 220);

Källkod

Gränssnitt - IDatabase.java

public interface IDatabase { public void updateScores(String studentId, int total); }

Klass under test - StudentScoreUpdates.java

public class StudentScoreUpdates { public IDatabase databaseImpl; public StudentScoreUpdates(IDatabase databaseImpl) { this.databaseImpl = databaseImpl; } public void calculateSumAndStore(String studentId, int() scores) { int total = 0; for(int score : scores) { total = total + score; } // write total to DB databaseImpl.updateScores(studentId, total); } }

Enhetstestklass - StudentScoreUpdatesUnitTests.java

public class StudentScoreUpdatesUnitTests { @Mock public IDatabase mockDatabase; public StudentScoreUpdates studentScores; @BeforeEach public void beforeEach() { MockitoAnnotations.initMocks(this); } @Test public void calculateSumAndStore_withValidInput_shouldCalculateAndUpdateResultInDb() { // Arrange studentScores = new StudentScoreUpdates(mockDatabase); int() scores = {60,70,90}; Mockito.doNothing().when(mockDatabase).updateScores(anyString(), anyInt()); // Act studentScores.calculateSumAndStore('student1', scores); // Assert Mockito.verify(mockDatabase, Mockito.times(1)).updateScores('student1', 230); } }

Slutsats

Det vi hittills såg är ett väldigt enkelt och enkelt exempel på Mock-installation med Java: s Mockito-ramverk.

För nästan 60-70% av enhetstester som involverar hånar bör testerna ha en liknande struktur. Mockito tillhandahåller mycket avancerad konfiguration / support för omfattande mockingbehov, injicerar mock-instanser med hjälp av beroendeinjektion, ger spioner att faktiskt spionera på ett riktigt metodsamtal och verifiera samtalen.

Vår kommande handledning kommer att förklara mer om begreppet Mocks and Spies i Mockito.

NÄSTA självstudie

Rekommenderad läsning

^