Menu

Mockito Tutorial: Mockito Framework for Mocking i Unit Testing

  • Vigtigste
  • Andet
  • Mockito Tutorial: Mockito Framework for Mocking i Unit Testing

mockito tutorial mockito framework

Prøv Vores Instrument Til At Fjerne Problemer

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

virtual reality-briller til Xbox 360

Enhedstest er en simpel, men effektiv teknik til at opnå et godt niveau af tillid til den kode, der skal sendes.

Desuden undgår det regressionsproblemer med hvert stykke kode, der bliver checket ind.

Med mikrotjenester-type arkitektur (og endda til simpel struktur, der involverer grundlæggende databaseopkald), er det ikke tilstrækkeligt at teste enheden. Hvad vi har brug for er at spotte afhængighederne og teste den faktiske logik af den testede metode.

Vejledning til Mockito-vejledning

Liste over ALLE Mockito-vejledninger i denne serie:

Tutorial # 1: Mockito Framework for Mocking i Unit Testing (Denne vejledning)
Tutorial # 2: Oprettelse af Mocks and Spies i Mockito
Tutorial # 3: Forskellige typer matchere leveret af Mockito
Tutorial # 4: Hån af private, statiske og ugyldige metoder ved hjælp af Mockito
Tutorial # 5: Top 12 Mockito Interview Spørgsmål

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

Oversigt over selvstudier i denne Mockito-serie

Vejledning #Hvad du vil lære
Tutorial # 1: Mockito Framework for Mocking i Unit Testing

Lær mocking med Mockito - En omfattende Mockito Tutorial for begyndere med kodeeksempler. Lær Mocking Framework for Mocking i Unit Testing.
Tutorial # 2: Oprettelse af Mocks and Spies i Mockito

Mocks and Spies er typer af testdobler, som er nyttige til at skrive enhedstest. Begge forklares i denne Mockito Spy-tutorial med kodeeksempler.
Tutorial # 3: Forskellige typer matchere leveret af Mockito

Lær hvordan du bruger forskellige typer matchere leveret af Mockito. Matchere er som jokertegn, hvor du i stedet for et bestemt input / output angiver et inputområde. Argument og verifikation er de to typer Matchers i Mockito, som forklares detaljeret her.
Tutorial # 4: Hån af private, statiske og ugyldige metoder ved hjælp af Mockito

Lær Mocking Private, Static og Void-metoder i Mockito med eksempler. Lær Mocking private og statiske metoder ved hjælp af enhedstestningsramme PowerMockito.
Tutorial # 5: Top 12 Mockito Interview Spørgsmål

Mockito Interview Spørgsmål og svar med eksempler på kodeeksempler. Dette hjælper dig med at knække ethvert Mockito Mocking Framework-interview med succes.

Lad os starte med den første tutorial i denne serie !!

Hvad du vil lære:

Mocking i enhedstest

Mocks / Stubs er et udtryk, som folk ofte hører, når de især opretter enhedstest.

Så hvad er egentlig Mocking? Enkelt sagt er det intet andet end at give en kontrolleret forekomst eller implementering af afhængighed, som koden under test afhænger af for at teste dens kernelogik.

Årsagen til, at jeg nævnte det som en kontrolleret instans, er, at afhængighedens opførsel kan programmeres eller styres efter ønske for den metode eller det testede system.

For at forklare det diagrammatisk, lad os tage et eksempel på enhver forretnings- eller e-handelsapplikation. Næsten enhver sådan type applikation har primært 3 lag, dvs. Brugergrænseflade, Business Layer & Data Access-lag (som taler til det underliggende datalager)

Eksempel: Enhedstestafhængighed

Med henvisning til ovenstående diagram har Business Layer 3 afhængigheder, dvs. Data Access Layer og 2 andre tjenester, der er Service 1 og Service 2.

Se på det på denne måde - En app som Google Maps kan have afhængighed af en

  1. Faktiske datalagre som MySQL eller andre ingen SQL-databaser, der gemmer kortdata.
  2. En ekstern tjeneste som CoordinateService, der giver breddegrader og længdegrader på et sted.
  3. En ekstern tjeneste som trafiktjeneste, der giver trafikoplysninger i realtid til et givet koordinatpar.

Så hvis nogen forsøger at validere kerneforretningslogikken ved hjælp af enhedstest, indtil og medmindre de har fungerende implementeringer af disse afhængigheder, kunne testene ikke køres.

Mocks kommer til undsætning i disse situationer, hvor uanset din afhængighed er i gang eller ej, er du altid garanteret at køre din forretningslogik med et programmeret svar til den afhængighed, der bliver kaldt fra den kode, der testes.

Typer / kategorier af testdobler

Mock er i det væsentlige en type 'Test Double' - det er en teknisk jargon. 'Test dobbelt' betyder i det væsentlige et objekt, der erstattes af tilsvarende ægte objektforekomst eller afhængighed.

Der er forskellige typer testdobler som nævnt nedenfor:

# 1) Falske:

En falsk er en fungerende implementering svarende til en reel afhængighed, bortset fra at den er lokal for det testede system.

Eksempel: I stedet for at ramme en reel produktions-DB bruger testen en simpel indsamling / hukommelse til at gemme data.

Type testdobler - forfalskninger

# 2) Stubbe:

Stubbe er forudkonfigurerede svar, når en afhængighed kaldes fra det testede system.

Type af fordobler - stubs

# 3) Spioner:

Som navnet antyder, er det faktisk det virkelige funktionsopkald (afhængighed) med en vis overvågningsmekanisme. Efter opkaldet kan det verificeres, om opkaldet faktisk blev udløst eller ikke sammen med parametrene.

Type af fordobler - Spioner

# 4) Mocks:

Mocks er specielle forekomster af objekter, hvor Stubbed / forudkonfigurerede svar kan specificeres. Det faktum, at mock blev kaldt, kan bekræftes som en påstand i testen.

For eksempel:

Der er en rapportgeneratorfunktion, der sender en e-mail til en bestemt adresse under udførelse.

Da vi ikke ønsker at sende den aktuelle e-mail igen og igen under test, bespottes EmailService (og e-mail-metoden, der sender e-mailen, er konfigureret til ikke at gøre noget, når det kaldes). I slutningen af ​​testen kan vi bare kontrollere, at e-mail-tjenestens e-mail-sendemetode blev kaldt gennem det spottede objekt.

Forskellige Mocking-rammer

Næsten alle sprog giver forskellige slags spottende rammer. Vi skriver en prøvekode ved hjælp af Mockito, som er en open source Mocking-ramme til Java.

Anatomi af en simpel enhedstest med hånet afhængighed. Antag, vi prøver at enhedstest en applikation, der beregner de samlede karakterer for en studerende 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); }

Hvis vi nu vil skrive en enhedstest til metoden - beregneSumAndStore, har vi muligvis ikke en reel implementering af en database til lagring af det samlede beløb. I så fald vil vi aldrig være i stand til at teste denne funktion.

Men med mocks på plads, kan vi simpelthen videregive en Mock til databasetjeneste og validere resten af ​​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 set i ovenstående test, vi har leveret et mockDatabase-objekt til overordnede klassen (for metoden under test), og vi har oprettet et stubrespons for det mockedDatabase-objekt - Linje # 6 ovenfor (Mockito.doNothing (). Når (mockDatabase) .updateScores ('student1', 220);)

De vigtige punkter at bemærke fra ovenstående er:

# 1) Det spottede objekt skal konfigurere stubbe-svar for alle de metoder, der kaldes til under udførelsen af ​​funktionen.

#to) De parametre, der er angivet under oprettelse af stub, kan være specifikke eller generiske.

Eksempel i ovennævnte tilfælde - vi har specificeret parametrene for updateScores-metoden som “student1” og 220, fordi vi ved, at dette er de nøjagtige input, som vores metode skal kaldes til.

# 3) Under verifikationen validerer vi følgende:

  • metoden mockDatabase.updateScores blev kaldt.
  • Argumenterne var henholdsvis “student1” og 220.
  • Metoden updateScores blev kaldt 1 gang.

Lad os nu ændre denne testkode lidt og se, hvad der sker:

Jeg vil ændre argumentet i mock-opsætningen fra 'student1' til anyString (Mockito leverer en standard matcher ved navn anyString ()) & 220 til anyInteger (Mockito leverer en standard matcher ved navn anyInt () og den matcher enhver heltal værdi)

@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 at køre testen igen, og testen skal stadig være grøn.

(Lad os nu ændre bekræftelse / påstande og ændre et hvilket som helst af argumenterne.

Lad os ændre 220 til 230. Nu forventes det, at testen skal mislykkes, da dette ikke er det forventede argument, som databaseUpdate skal have været kaldt 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 kørsel af testen henvises til fejlloggene som vist nedenfor (det nævnes tydeligt, at de faktiske argumenter ikke matchede de forventede).

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

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

Kildekode

Grænseflade - IDatabase.java

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

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

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

Konklusion

Det, vi hidtil har set, er et meget grundlæggende og ligetil eksempel på Mock-opsætning ved hjælp af Java's Mockito-ramme.

For næsten 60-70% af enhedstest, der involverer mocks, skal testene have en lignende struktur. Mockito giver en masse avanceret konfiguration / support til omfattende mocking-behov, injicerer mock-forekomster ved hjælp af afhængighedsinjektion, giver Spies til faktisk at spionere på et rigtigt metodeopkald og kontrollere opkaldene.

Vores kommende tutorial forklarer mere om begrebet Mocks and Spies i Mockito.

NÆSTE vejledning

Anbefalet læsning

^