Meny

Mockito Tutorial: Mockito Framework for Mocking in Unit Testing

  • Hoved
  • Annen
  • Mockito Tutorial: Mockito Framework for Mocking in Unit Testing

mockito tutorial mockito framework

Prøv Instrumentet Vårt For Å Eliminere Problemer

En komplett guide til Mockito Framework: Hands-on Mockito Tutorials

hvordan du skriver ut strengarray i java ved hjelp av for loop

Enhetstesting er en enkel, men effektiv teknikk for å få et godt nivå av tillit til koden som skal sendes.

Videre unngår det regresjonsproblemer med hver kode som blir sjekket inn.

Med mikrotjenester slags arkitektur (og til og med for enkel struktur som involverer grunnleggende databasesamtaler), er ikke enkel enhetstesting tilstrekkelig. Det vi trenger er å spotte avhengighetene og teste den faktiske logikken til metoden som testes.

Veiledning for Mockito

Liste over ALLE Mockito-opplæringsprogrammer i denne serien:

Opplæring # 1: Mockito Framework for Mocking in Unit Testing (Denne opplæringen)
Opplæring # 2: Å lage Mocks and Spies i Mockito
Opplæring # 3: Ulike typer matchere levert av Mockito
Opplæring # 4: Spotte private, statiske og ugyldige metoder ved bruk av Mockito
Opplæring # 5: Topp 12 Mockito intervju spørsmål

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

Oversikt over opplæringsprogrammer i denne Mockito-serien

Opplæringen #Hva du vil lære
Opplæring # 1: Mockito Framework for Mocking in Unit Testing

Lær mocking med Mockito - En omfattende Mockito Tutorial for nybegynnere med kodeeksempler. Lær Mocking Framework for Mocking i Unit Testing.
Opplæring # 2: Å lage Mocks and Spies i Mockito

Mocks and Spies er typer testdobler, som er nyttige for å skrive enhetstester. Begge er forklart i denne Mockito Spy-opplæringen med kodeeksempler.
Opplæring # 3: Ulike typer matchere levert av Mockito

Lær hvordan du bruker forskjellige typer matchere levert av Mockito. Matchere er som jokertegn der du i stedet for en bestemt inngang / utgang spesifiserer et utvalg av innganger. Argument og bekreftelse er de to typene Matchers i Mockito som blir forklart i detalj her.
Opplæring # 4: Spotte private, statiske og ugyldige metoder ved bruk av Mockito

Lær Mocking Private, Static og Void metoder i Mockito med eksempler. Lær Mocking private og statiske metoder ved enhetstesting rammeverk PowerMockito.
Opplæring # 5: Topp 12 Mockito intervju spørsmål

Mockito Intervju Spørsmål og svar med eksempler på eksempelkoder. Dette vil hjelpe deg med å knekke ethvert Mockito Mocking Framework-intervju med suksess.

La oss starte med den første opplæringen i denne serien !!

Hva du vil lære:

Spott i enhetstesting

Mocks / Stubs er et begrep som folk ofte hører når de oppretter enhetstester spesielt.

Så, hva er egentlig Mocking? Enkelt sagt er det ingenting annet enn å gi en kontrollert forekomst eller implementering av avhengighet som koden under test er avhengig av for å teste kjernelogikken.

Årsaken til at jeg nevnte det som en kontrollert forekomst er at avhengighetens oppførsel kan programmeres eller kontrolleres etter ønske for metoden eller systemet som testes.

For å forklare det skjematisk, la oss ta et eksempel på en hvilken som helst forretnings- eller netthandelsapplikasjon. Nesten alle slike applikasjoner har primært 3 lag, dvs. Brukergrensesnitt, Business Layer & Data Access-lag (som snakker med den underliggende datalageret)

Eksempel: Avhengighet for enhetstesting

Med henvisning til diagrammet ovenfor har Business Layer tre avhengigheter, dvs. Data Access Layer og 2 andre tjenester som er Service 1 og Service 2.

Se på det på denne måten - En app som google maps kan ha avhengighet av en

  1. Faktiske datalagre som MySQL eller andre ingen SQL-databaser som lagrer kartdata.
  2. En ekstern tjeneste som CoordinateService som gir breddegrader og lengdegrader på et sted.
  3. En ekstern tjeneste som trafikktjeneste som gir sanntids trafikkinformasjon for et gitt koordinatpar.

Så hvis noen prøver å validere kjernevirksomhetens logikk ved hjelp av enhetstest, til og med mindre de har fungerende implementeringer av disse avhengighetene, kan ikke testene kjøres.

Mocks kommer til å redde i disse situasjonene, uansett om avhengigheten din er i gang eller ikke, er du alltid garantert å kjøre forretningslogikken din med et programmert svar for avhengigheten som blir ringt fra koden som testes.

Typer / kategorier av testdobler

Mock er egentlig en type 'Test Double' - det er en teknisk sjargong. 'Test Double' betyr i hovedsak et objekt som erstattes av tilsvarende ekte objektforekomst eller avhengighet.

Det er forskjellige typer testdobler som nevnt nedenfor:

# 1) Forfalskninger:

En falsk er en fungerende implementering som ligner på en reell avhengighet, bortsett fra at den er lokal for systemet som testes.

Eksempel: I stedet for å treffe en ekte produksjons-DB, bruker testen en enkel samling / in-memory for å lagre data.

Type testdobler - forfalskninger

# 2) Stubber:

Stubber er forhåndskonfigurerte svar når en avhengighet kalles fra systemet som testes.

Type testdobler - stubber

# 3) Spioner:

Som navnet antyder, er det faktisk den virkelige funksjonen (avhengighet) samtale med noen overvåkingsmekanismer. Legg ut samtalen, det kan verifiseres om samtalen faktisk ble utløst eller ikke sammen med parametrene.

Type Testdobler - Spioner

# 4) Håner:

Mocks er spesielle forekomster av objekter der du kan spesifisere Stubbed / pre-configured response. Det faktum at mock ble ringt kan bekreftes som en påstand i testen.

For eksempel:

Det er en rapportgeneratorfunksjon som sender en e-post til en spesifisert adresse under kjøring.

Siden vi ikke vil sende ekte e-post, igjen og igjen, under testing, blir EmailService hånet (og e-postmetoden som sender e-posten er konfigurert til å gjøre ingenting når den heter). På slutten av testen kan vi bare bekrefte at e-posttjenestens sendemetode ble ringt gjennom det spottede objektet.

Ulike Mocking Frameworks

Nesten alle språkene gir forskjellige typer spottende rammer. Vi vil skrive en eksempelkode ved hjelp av Mockito, som er et åpen kildekode Mocking-rammeverk for Java.

Anatomi av en enkel enhetstest med hånet avhengighet. Anta at vi prøver å teste en applikasjon som beregner totale karakterer for en student i alle fagene og skriver den til 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); }

Nå hvis vi ønsker å skrive en enhetstest for metoden - beregneSumAndStore, har vi kanskje ikke en reell implementering av en database for å lagre totalen. I så fall vil vi aldri kunne teste denne funksjonen.

Men med mocks på plass, kan vi ganske enkelt sende en Mock for database-tjeneste og validere resten av logikken

Prøveprøve som vist nedenfor:

@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 testen ovenfor, vi har gitt et mockDatabase-objekt til foreldreklassen (for metoden som testes), og vi har satt opp en stubrespons for mockedDatabase-objektet - Linje # 6 ovenfor (Mockito.doNothing (). Når (mockDatabase) .updateScores (“student1”, 220);)

De viktige punktene å merke seg fra ovenstående er:

#1) Det spottede objektet må sette opp stubbede svar for alle metodene som vil bli kalt under funksjonens utførelse.

#to) Parametrene som er spesifisert under stubbopprettelsen kan være spesifikke eller generiske.

Eksempel i ovennevnte tilfelle - vi har spesifisert parametrene for updateScores-metoden som 'student1' og 220 fordi vi vet at dette er de nøyaktige inngangene som metoden vår vil bli kalt til.

# 3) Under verifisering validerer vi følgende:

  • mockDatabase.updateScores-metoden ble kalt.
  • Argumentene var henholdsvis “student1” og 220.
  • UpdateScores-metoden ble kalt 1 gang.

La oss nå prøve å endre denne testkoden litt og se hva som skjer:

Jeg vil endre argumentet i mock-oppsettet fra “student1” til anyString (Mockito gir en standard matcher kalt anyString ()) & 220 til anyInteger (Mockito gir en standard matcher kalt anyInt () og den samsvarer med en heltallverdi)

@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); }

Prøv å kjøre testen igjen, og testen skal fortsatt være grønn.

(La oss nå prøve å endre bekreftelsen / påstandene og endre noen av argumentene.

La oss endre 220 til 230. Nå er forventningen at testen skal mislykkes, da dette ikke er det forventede argumentet som databaseUpdate må ha blitt ringt 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); }

Etter å ha kjørt testen, se feilloggene som vist nedenfor (det nevnes tydelig at de faktiske argumentene ikke samsvarte med de forventede).

Argument (er) er forskjellige! Ønsket:
mockDatabase.updateScores (“student1”, 230);
-> på com.mocking.sampleMocks.StudentScoreUpdatesUnitTests.calculateSumAndStore_withValidInput_shouldCalculateAndUpdateResultInDb (StudentScoreUpdatesUnitTests.java:37)

Faktisk påkallelse har forskjellige argumenter:
mockDatabase.updateScores (“student1”, 220);

Kildekode

Grensesnitt - IDatabase.java

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

Class 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); } }

Enhetstestklasse - 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); } }

Konklusjon

Det vi så hittil er et veldig grunnleggende og greit eksempel på Mock-oppsett ved bruk av Java’s Mockito framework.

I nesten 60-70% av enhetstester som involverer mocks, bør testene ha en lignende struktur. Mockito gir mye avansert konfigurasjon / støtte for omfattende mocking-behov, injiserer mock-forekomster ved hjelp av avhengighetsinjeksjon, gir Spioner til å faktisk spionere på en ekte metodeanrop og verifisere samtalene.

Vår kommende veiledning vil forklare mer om begrepet Mocks and Spies i Mockito.

NESTE veiledning

Anbefalt lesing

^