top 12 mockito interview questions
Ofte stilte spørsmål om Mockito-intervju for å knekke Mockito-spottende intervju:
I vår forrige opplæring lærte vi Private, statiske og ugyldige metoder for spott . Les gjennom fullfør opplæringsveiledninger om Mockito for en klar forståelse av Mockito-rammeverket.
Denne artikkelen dekker de vanligste stilte intervjuspørsmålene om Mockito Mocking-rammeverket.
Det forventes at enhver utvikler eller kvalitetssikring kjenner til Mocking-grunnleggende for å kunne skrive de fleste hvitbokstestene (eller enhetstester) med letthet og å spotte avhengighetene for forbedret kodedekning og større tillit til applikasjonen.
Mest populære Mockito intervju spørsmål med detaljerte svar
Her er de vanligste spørsmålene om Mocking Frameworks.
Q # 1) Hvorfor trenger vi spott?
Svar: Det er mange bruksområder med hån som hjelper til med enhetstesting av koden under isolasjon og gjør testen svært repeterbar og forutsigbar.
Hån er vanligvis nødvendig når:
til) Komponenten som testes har avhengigheter som ennå ikke er implementert eller implementeringen pågår.
Et godt eksempel kan være et REST API-endepunkt som vil være tilgjengelig senere på et tidspunkt, men du har brukt det i koden via en avhengighet.
Nå som den virkelige implementeringen fremdeles ikke er tilgjengelig, vet du virkelig mesteparten av tiden hva som er det forventede svaret fra det APIet. Mocks lar deg teste slike integrasjoner.
b) Komponent oppdaterer tilstanden i systemet.
Eksempel: DB-samtaler - du vil ikke oppdatere DB-en din med data som bare er for testformål. Dette kan føre til at data blir ødelagt. Dessuten er tilgjengeligheten av DB en annen utfordring når testen utføres.
For å unngå slik oppførsel kan DB-samtaler spottes i komponenten som testes. Derfor er det ingen direkte kobling av DB og komponenten som testes.
Q # 2) Forskjell mellom doReturn og thenReturn.
Svar: Mockito gir to forskjellige syntakser for å lage stubber som:
- doReturn og deretterReturn
- gjør ingenting (ikke da ingenting)
- kast og deretter kast
Begge disse metodene setter opp stubber og kan brukes til å lage / sette opp stubber og kan til tider brukes om hverandre.
hvor er nettverkssikkerhetsnøkkelen min
Så hvordan skiller begge disse seg?
til) ThenReturn-måten å stubbe på er en typesikker måte å sette opp stubber på. Hva dette egentlig betyr er at det gjør en tidssjekk mot returtypene du også vil stubbe.
La oss forstå dette med et eksempel:
Anta en metode getItemDetails på mockedItemService som returnerer et objekt av typen ItemSku. Så med deretter Retur, du vil ikke være i stand til å returnere noe annet enn av typen ItemSku, men med doReturn kan du sette opp stubben for å returnere noe, og testen mislykkes (eller kaster et unntak) under utførelsen.
// virker
when (mockedItemService.getItemDetails(123)).thenReturn(new ItemSku());// kaster kompileringstid unntak
when (mockedItemService.getItemDetails(123)).thenReturn(expectedPrice);// med doReturn fungerer begge stuboppsettet da det ikke er kompilert trygt.
// her prøver vi å returnere et objekt av typen dobbelt som fortsatt fungerer og ikke kaster noen kompileringstidvarsel.
doReturn (expectedPrice).when(mockedItemService.getItemDetails(123)); doReturn (new ItemSku()).when(mockedItemService.getItemDetails(123));b) En annen viktig forskjell mellom disse to måtene til stubben er for Mocked objekter, bortsett fra kompileringssikkerhet er det ikke mye forskjell.
Men for spionerte objekter vil 'thenReturn' -formen for stubbe ikke fungere, da det vil resultere i å ringe den virkelige metoden før den stubbede responsen er tilbake som samtalen og ikke på en Mock, men på Spy som pakker inn en ekte objektforekomst. .
Så anta at det er en spion som heter spiedObject og den har en metodetestMetode som returnerer et heltall, for å sette opp en stubbe på dette må du bruke doReturn i stedet for thenReturn.
doReturn (10).when(spiedObject.testMethod());Q # 3) Når og hvorfor skal en spion brukes?
Svar: Spy er en type delvis mock støttet av Mockito.
Dette betyr egentlig er en type forekomst der:
til) Når ingen mock er satt opp, resulterer enhver interaksjon på spion i å kalle de virkelige metodene. Men det lar deg likevel verifisere samspillet med det spionerte objektet som - var en metode som faktisk ble kalt, hvor mange ganger metoden ble kalt, hva var argumentene som metoden ble kalt til etc.
b) Det gir deg fleksibilitet til å sette opp delvise mocks.
For eksempel, hvis du har et objekt med to metoder - metode1 og metode2 og du vil at metode1 skal kalles og metode2 bespottes. Spioner tilbyr denne typen oppsett.
Så forskjellen mellom en mock og en stub i enkle termer er - en mock er opprettet fra en type og ikke fra en forekomst, mens en stub bryter en faktisk forekomst av klasseobjektet.
Spørsmål nr. 4) Hvorfor kan ikke statiske metoder spottes med Mockito?
sirkulær koblet liste c ++
Svar: Statiske metoder er knyttet til selve klassen og ikke noen spesiell forekomst av klassen. Dette betyr at alle forekomster / objekter i klassen bruker samme forekomst av den statiske metoden.
Statiske metoder er mer som prosedyrekode og brukes mest i eldre systemer generelt.
Mock-biblioteker oppretter vanligvis mocks ved å opprette dynamisk forekomst ved kjøretid, enten via grensesnitt eller gjennom arv, og da den statiske metoden ikke er knyttet til noen spesiell forekomst, er det ikke mulig for mocking-rammer (som mockito, easy mock, etc) å spotte statiske metoder.
Rammeverk som PowerMock, som har støtte for statiske metoder, utfører bytecode-manipulering på kjøretid for å spotte statiske metoder.
Q # 5) Hva er behovet for å bekrefte at mock ble kalt?
Svar: Å sette opp en stub på et hånet objekt (eller en spionert forekomst) garanterer ikke om det stubbede oppsettet til og med ble påkalt.
'Verifikasjon' matchere, gi muligheten til å validere om stubben som ble satt opp faktisk ble påkalt eller ikke, hvor mange ganger ble samtalen foretatt, hvilke argumenter ble den stubmetoden kalt med osv.
I hovedsak lar det oss verifisere testoppsettet og forventet resultat på en mer robust måte.
Sp # 6) Hva er en god testbar kode?
Svar:
Få punkter om testbar kode (noe som lett kan testes enhet) inkluderer:
- Redusert antall avhengigheter eller tett kobling - Eksempel: Avhengigheter bør injiseres i stedet for å instantiseres direkte.
- Kode som følger SRP (Single Responsibility Principle) - Dette betyr i hovedsak at klassen ikke skal ha flere grunner til å endre seg. Overholdelse av SRP unngår klasser som skaper avhengighet av seg selv og holder koden sammenhengende og ren.
- Mindre / Minimal bruk av statiske metoder og avsluttende klasser - Disse indikerer vanligvis kodelukt og var hovedsakelig forbundet med den eldre koden.
Sp # 7) Hva er begrensningene til Mockito?
Svar: Mockito er et rammeverk for de fleste Java-baserte prosjekter. Det er enkelt å implementere, lese og forstå.
Noen av ulempene eller begrensningene når det gjelder funksjonalitet er:
- Dens manglende evne til å spotte statiske metoder.
- Konstruktører, private metoder og avsluttende klasser kan ikke hånes.
Sp # 8) Hvilke rammer kan støtte spottende private og statiske metoder?
Svar: Rammeverk som PowerMockito (utvidelser av Mockito framework), JMockit, etc. gir midler til å spotte private og statiske metoder.
Q # 9) Mocking / Stubbing standardmetoder i Interface i Java 8.
Svar: Med Java 8s implementering av standardmetoder i Interface, gir Mockito støtte utenom boksen for å spotte slike standardmetoder. (Vær oppmerksom på at denne støtten ble introdusert fra Mockito 2 og utover).
Disse metodene kan spottes / stubbes som alle andre metoder i en klasse eller grensesnitt.
Sp # 10) Hvordan kan bestilling av stubbeinnkallinger verifiseres i Mockito?
Svar: Når du vil bekrefte rekkefølgen mocks ble kalt til, er Mockitos I rekkefølge ”Grensesnitt kan brukes.
I løpet av testen må du bare sette opp / opprette et Inorder-objekt, og oppføre en liste over mock-objekter som rekkefølgen på mocks må fastslås på (hvis det er flere metoder på samme mock og det ikke er noen annen mock som trenger for å bli bekreftet, er det tilstrekkelig å nevne den hånede klassen bare en gang).
Tenk på testen nedenfor som definerer et objekt av InOrder og nevner to forekomster av mockDatabaseImpl
@Test public void calculateSumAndStore_withValidInput_verifyMockOrder() { // Arrange studentScores = new StudentScoreUpdates(mockDatabaseImpl); int() scores = {60,70,90}; Mockito.doNothing().when(mockDatabaseImpl).updateScores(anyString(), anyInt()); Mockito.doReturn('A').when(mockDatabaseImpl).getGrade(anyInt()); InOrder inorder = inOrder(mockDatabaseImpl); // Act studentScores.calculateSumAndStore('Student1', scores); // Assert inorder.verify(mockDatabaseImpl).updateScores(anyString(),anyInt()); inorder.verify(mockDatabaseImpl).getGrade(anyInt()); } Som referanse kan det være nyttig å liste opp koden for metoden som testes for å forstå rekkefølgen på testutførelsen:
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); databaseImpl.getGrade(total); }Som vist ovenfor, kaller databaseImpl først updateScores og deretter samtaler getGrade.
Så hvis du skriver en enhetstest med Mockito, for dette og du må sørge for rekkefølgen på samtalene på databaseImpl, se testkoden og sørg for at påstandene blir utført i henhold til den forventede bestillingen.
I eksemplet ovenfor, hvis jeg endrer rekkefølgen på påstander, vil det føre til at testen mislykkes med unntak av 'VerificationInOrderFailure'.
Etter å ha endret påstandsrekkefølgen ser koden ut som vist nedenfor:
@Test public void calculateSumAndStore_withValidInput_verifyMockOrder() { // Arrange studentScores = new StudentScoreUpdates(mockDatabaseImpl); int() scores = {60,70,90}; Mockito.doNothing().when(mockDatabaseImpl).updateScores(anyString(), anyInt()); Mockito.doReturn('A').when(mockDatabaseImpl).getGrade(anyInt()); InOrder inorder = inOrder(mockDatabaseImpl); // Act studentScores.calculateSumAndStore('Student1', scores); // Assert inorder.verify(mockDatabaseImpl).updateScores(anyString(),anyInt()); inorder.verify(mockDatabaseImpl).getGrade(anyInt()); } Ovennevnte testutførelse gir et unntak med typen:
“VerificationInOrderFailure” org.mockito.exceptions.verification.VerificationInOrderFailure:
Bekreftelse i bestillingsfeil
Ønsket men ikke påkalt:
mockDatabaseImpl.updateScores (
isA (java.lang.String),
isA (java.lang.Integer)
Q # 11) Returnerer flere verdier mot påfølgende metodeanrop
Svar: For å returnere forskjellige verdier for flere påkallinger av samme stubmetode, gir Mockito tre tilnærminger som gitt nedenfor:
til) Ved hjelp av komma skilt: Dette fungerer med thenReturn.
For eksempel , tar vi ovennevnte kodeeksempel, la oss prøve å sette opp påfølgende stub for metode - getGrade som vil returnere forskjellige verdier avhengig av rekkefølgen av iterasjoner:
dobbeltkoblet liste c ++ kode
when (mockDatabaseImpl.getGrade( anyInt ())).thenReturn('A','B', 'C');Dette betyr at når getGrade-metoder blir kalt inn i metoden som testes, vil den første påkallingen returnere 'A', den andre påkallingen vil returnere 'B' og så videre.
b) Påfølgende deretterRetur: Dette er en tilnærming som er lenket med uttalelser fra da. Å bruke kjedede anrop til det samme eksemplet vil se ut som vist nedenfor.
when (mockDatabaseImpl.getGrade( anyInt ())).thenReturn('A').thenReturn('B').thenReturn('C');c) Påfølgende doReturn: Den siste tilnærmingen er å bruke doReturn i lenket format som ovenfor.
doReturn ('A').doReturn('B').doReturn('C').when(mockDatabaseImpl).getGrade( anyInt ())Sp # 12) Hva er de forskjellige typene spottende rammer og hvordan fungerer de?
Svar: Typer av Mocking-rammeverket og hvordan de fungerer forklares nedenfor.
Det er stort sett to kategorier spottende rammer:
- Proxy-basert - Eksempel, Mockito, EasyMock, etc.
- Bytecode basert - Eksempel, PowerMock, JMockit, etc.
La oss sammenligne begge disse rammene på forskjellige parametere.
| Proxy basert | Bytecode basert | |
|---|---|---|
| Enkelt | Mer enkel og enkel å bruke | Kan innebære en kompleks logikk med mock-oppsett |
| Opprettelsesmåte | Det opprettes en proxy eller et falskt objekt som ikke krever klasse / grensesnitt | Det innebærer i hovedsak å lage objekter og ved kjøretid manipulerer forekomsten for spottet / stubben oppførsel |
| Funksjonalitet | Spottende klasser og grensesnitt | I tillegg til klasser og grensesnitt, tillater spottende statiske metoder, sluttklasser osv |
| Java avhengighet | Ikke veldig tett koblet til java-versjoner | Siden disse rammene involverer manipulering av kodekoder, er de tett koblet og er kanskje ikke bakover / fremover kompatible på tvers av java-versjoner. |
| Eksempler | Mockito, EasyMock etc. | PowerMock, JMockit etc. |
Konklusjon
Innholdet som dekkes i denne artikkelen serverer grunnleggende diskusjoner rundt Mocking-rammer og spesielt Mockito-intervjuforberedelse.
I tillegg til å få en teoretisk forståelse av spørsmålene som dekkes, bør man også prøve å gjøre ekte kodeeksempler som gjør læring av disse rammene morsommere og mer interessant.
Håper, du likte hele veiledningen i denne Mockito-serien.
Glad læring.
PREV Opplæring | FØRSTE veiledning
Anbefalt lesing
- Intervju spørsmål og svar
- Mockito Tutorial: Mockito Framework for Mocking in Unit Testing
- Noen interessante intervjusspørsmål om programvaretesting
- ETL Testing Intervju Spørsmål og svar
- Top Oracle Forms and Reports Interview Questions
- Programvarehåndbok Testing av intervjuspørsmål for erfarne fagpersoner
- Topp Oracle Apps tekniske spørsmål og Oracle SOA intervju spørsmål
- 25 beste spørsmål om svar og svar på smidig testing