top 12 mockito interview questions
Najpogostejša vprašanja o Mockito Intervjuju, da bi rešili Mockito Mocking Interview:
V prejšnji vaji smo se naučili Zasebne, statične in neveljavne metode posmehovanja . Preberite popolne vadnice za usposabljanje o Mockitu za jasno razumevanje okvira Mockito.
Ta članek zajema najpogostejša vprašanja o pogostih intervjujih v okviru Mockito Mocking.
Od vsakega razvijalca ali QA se pričakuje, da pozna osmešne osnove, da lahko z lahkoto napiše največ testov belega polja (ali enote) in se norčuje iz odvisnosti za izboljšano pokritost kode in večje zaupanje v aplikacijo.
Najbolj priljubljena vprašanja za intervju z Mockito s podrobnimi odgovori
Spodaj so navedena najpogostejša vprašanja o Mocking Frameworks.
V # 1) Zakaj potrebujemo posmehovanje?
Odgovor: Obstaja veliko primerov posmehovanja, ki pomagajo pri enostavnem preskušanju izolirane kode in naredijo test zelo ponovljiv in predvidljiv.
Posmehovanje je običajno potrebno, kadar:
do) Preskušana komponenta ima odvisnosti, ki še niso implementirane ali pa izvajanje poteka.
Dober primer je lahko končna točka API-ja REST, ki bo v določenem trenutku na voljo pozneje, vendar ste jo v odvisnosti porabili v kodi.
Ker dejanska izvedba še vedno ni na voljo, res večino časa veste, kakšen je pričakovani odziv tega API-ja. Posmehi vam omogočajo, da preizkusite te vrste integracije.
b) Komponenta posodablja stanje v sistemu.
Primer: Klici DB - ne bi želeli posodobiti DB s podatki, ki so namenjeni samo testiranju. To lahko povzroči poškodovanje podatkov, poleg tega pa je razpoložljivost DB še en izziv, ko se test izvede.
Tako bi se izognili takšnemu vedenju, klici DB se lahko posmehujejo v preizkušeni komponenti. Zato ni neposrednega povezovanja DB in preskušane komponente.
V # 2) Razlika med doReturn in thenReturn.
Odgovor: Mockito ponuja dve različni sintaksi za ustvarjanje škrbine, kot so:
- doReturn in natoReturn
- ne delaj nič (ne takrat nič)
- doThrow in natoThrow
Oba načina nastavitve škrbine in jih je mogoče uporabiti za ustvarjanje / nastavitev škrbine in jih je mogoče včasih uporabljati zamenljivo.
kateri ide je najboljši za python
Torej, kako se oba razlikujeta?
do) Način potiskanja thenReturn je varen način nastavitve škrbine. To v bistvu pomeni, da opravi preverjanje časa prevajanja glede na vrste vrnitve, ki jih želite tudi omamiti.
Razumimo to na primeru:
Predpostavimo metodo getItemDetails na mockedItemService ki vrne objekt tipa ItemSku. Torej z thenReturn, ne boste mogli vrniti ničesar drugega kot tipa ItemSku, vendar z doReturn lahko nastavite škrbino, da vrne karkoli, in test med izvajanjem ne bo uspel (ali vrgel izjeme).
// deluje
when (mockedItemService.getItemDetails(123)).thenReturn(new ItemSku());// vrže izjemo časa prevajanja
when (mockedItemService.getItemDetails(123)).thenReturn(expectedPrice);// z doReturn tako nastavitev škrbine deluje, ker ni varna za prevajanje.
// tukaj poskušamo vrniti objekt tipa double, ki še vedno deluje in ne vrže nobenega opozorila o času prevajanja.
doReturn (expectedPrice).when(mockedItemService.getItemDetails(123)); doReturn (new ItemSku()).when(mockedItemService.getItemDetails(123));b) Druga pomembna razlika med tema dvema načinoma do škrbine je za posmehljive predmete, razen varnosti pri prevajanju ni veliko razlike.
Vendar pa za izvidene predmete vrsta nastavitve škrbine »thenReturn« ne bo delovala, saj bo povzročila klic prave metode, preden se kratek odziv vrne kot klic in ne na Mock, ampak na Spy, ki zavija primerek resničnega predmeta .
Predpostavimo, da obstaja vohun z imenom spiedObject in ima metodo testMethod, ki vrne celo število, nato pa boste za nastavitev škrbine na tem morali uporabiti doReturn namesto thenReturn.
doReturn (10).when(spiedObject.testMethod());V # 3) Kdaj in zakaj je treba uporabljati vohuna?
Odgovor: Vohun je vrsta delnega posmeha, ki ga podpira Mockito.
To v bistvu pomeni, da je vrsta primera, kjer:
do) Ko noben posmeh ni nastavljen, vsaka interakcija vohuna povzroči klicanje pravih metod. Vendar vam še vedno omogoča preverjanje interakcij z izvidljenim objektom, na primer - ali je bila metoda dejansko poklicana, kolikokrat je bila metoda klicana, kakšni so bili argumenti, s katerimi je bila metoda imenovana itd.
b) Omogoča vam prilagodljivost pri nastavitvi delnih posmehov.
Na primer, če imate objekt z dvema metodama - method1 in method2 in želite, da se pokliče method1 in se posmehuje method2. Tovrstne nastavitve zagotavljajo vohuni.
Torej, razlika med posmehom in škrbino v preprostih izrazih je - posnetek je ustvarjen iz vrste in ne iz primerka, medtem ko škrbina zavije dejanski primerek predmeta razreda.
V # 4) Zakaj se z uporabo Mockita ne moremo posmehovati statičnim metodam?
nedefiniran sklic na funkcijo c ++
Odgovor: Statične metode so povezane s samim razredom in ne z nobenim primerom razreda. To pomeni, da vsi primerki / predmeti razreda uporabljajo isti primerek statične metode.
Statične metode so bolj podobne postopkovni kodi in se večinoma uporabljajo v starih sistemih na splošno.
Lažne knjižnice ponavadi ustvarijo posmehe z dinamičnim ustvarjanjem primerkov med izvajanjem, bodisi prek vmesnikov bodisi z dedovanjem, in ker statična metoda ni povezana z nobenim primerkom, posmehovalnim ogrodjem (na primer mockito, easy mock itd.) Ni mogoče posmehovati statičnih metod.
Okviri, kot je PowerMock, ki imajo podporo za statične metode, med izvajanjem izvajajo manipulacijo z bajtno kodo, da bi se posmehovali statičnim metodam.
V # 5) Kaj je treba preveriti, ali je bil lažni klic poklican?
Odgovor: Nastavitev škrbine na posmehljivem predmetu (ali vohunjenem primerku) ne zagotavlja, ali je bila klicana nastavitev sploh poklicana.
'Verifikacijske' ujemanja, omogoči preverjanje, ali je bil nastavljeni klic dejansko poklican ali ne, kolikokrat je bil opravljen klic, s katerimi argumenti je bila klicana metoda itd.
V bistvu nam omogoča, da bolj zanesljivo preverimo nastavitve testa in pričakovani izid.
V # 6) Kaj je dobra preizkusna koda?
Odgovor:
Nekaj točk o preizkusni kodi (kar pomeni, da jo je mogoče enostavno preizkusiti na enoti) vključuje:
- Zmanjšano število odvisnosti ali tesno spenjanje - Primer: Odvisnosti je treba vbrizgati, namesto da bi jih ustvarili neposredno.
- Koda, ki upošteva SRP (načelo enotne odgovornosti) - To v bistvu pomeni, da razred ne bi smel imeti več razlogov za spremembo. Upoštevanje SRP preprečuje, da bi razredi ustvarjali odvisnost od sebe in ohranjalo kodo povezano in čisto.
- Manj / minimalna uporaba statičnih metod in končni razredi - Ti običajno označujejo vonj kode in so bili večinoma povezani s staro kodo.
V # 7) Kakšne omejitve ima Mockito?
Odgovor: Mockito je izbirni okvir za večino projektov, ki temeljijo na javi. To je enostavno izvesti, prebrati in razumeti.
Nekatere pomanjkljivosti ali omejitve v smislu funkcionalnosti so:
- Njegova nezmožnost norčevanja statičnih metod.
- Konstruktorjev, zasebnih metod in zaključnih razredov ni mogoče posmehovati.
V # 8) Kateri okviri lahko podpirajo posmehovanje zasebnim in statičnim metodam?
Odgovor: Okviri, kot so PowerMockito (razširitve okvira Mockito), JMockit itd., Ponujajo sredstva za posmeh zasebnim in statičnim metodam.
V # 9) Posmehovanje / preprečevanje privzetih metod v vmesniku v Javi 8.
Odgovor: Z implementacijo privzetih metod vmesnika Java 8 v vmesniku Mockito nudi pripravljeno podporo za posmeh takim privzetim metodam. (Upoštevajte, da je bila ta podpora uvedena od Mockito 2 naprej).
Te metode se lahko posmehujejo / nataknejo kot vse druge metode razreda ali vmesnika.
V # 10) Kako je mogoče v Mockitu preveriti vrstni red klicev s škrbino?
Odgovor: Ko želite preveriti vrstni red, v katerem so klicali zasmehovanje, Mockitovo InOrder ”Se lahko uporabi vmesnik.
Med preskusom morate preprosto nastaviti / ustvariti predmet Inorder, tako da navedete seznam lažnih predmetov, na katerih je treba določiti vrstni red posmehov (če je v istem lažnem sporočilu več metod in ni nobenega drugega lažnega, ki bi potreboval da se preveri, potem je dovolj, da oponašani razred omenimo le enkrat).
Razmislite o spodnjem preizkusu, ki opredeljuje objekt InOrder in omenja 2 pojavitve 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()); } Tudi za referenco vam bo lažje razumeti vrstni red izvedbe testa naštevanje kode preskušane metode:
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); }Kot je razvidno zgoraj, databaseImpl najprej pokliče updateScores in nato pokliče getGrade.
Torej, če pišete test enote z Mockito, morate za to in morate zagotoviti vrstni red klicev na databaseImpl, se sklicevati na testno kodo in zagotoviti, da so trditve narejene po pričakovanem vrstnem redu.
Če v zgornjem primeru spremenim vrstni red trditev, bo test spodletel, z izjemo »VerificationInOrderFailure«.
Po spremembi vrstnega reda uveljavljanja je koda videti, kot je prikazano spodaj:
@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()); } Zgornje izvajanje preizkusa vrže izjemo s tipom:
“VerificationInOrderFailure” org.mockito.exceptions.verification.VerificationInOrderFailure:
Preverjanje napake naročila
Zaželena, vendar ne uporabljena:
mockDatabaseImpl.updateScores (
isA (java.lang.String),
isA (java.lang.Integer)
najboljši čistilec neželenih datotek za Windows 10
V # 11) Vrnitev več vrednosti proti zaporednim klicem metode
Odgovor: Za vrnitev različnih vrednosti za več klicev iste kleščeče metode Mockito ponuja tri pristope, kot je navedeno spodaj:
do) Uporaba ločenih vejic: To deluje s funkcijo thenReturn.
Na primer , če vzamemo zgornji vzorec kode, poskusimo nastaviti zaporedne škrbine za metodo - getGrade, ki bo vrnila različne vrednosti, odvisno od zaporedja ponovitev:
when (mockDatabaseImpl.getGrade( anyInt ())).thenReturn('A','B', 'C');To pomeni, da bo, ko bodo metode getGrade poklicane v preizkušeni metodi, prvi klic vrnil 'A', drugi klic pa 'B' itd.
b) Zaporedni nato Vrnitev: To je pristop, ki je povezan z izjavami thenReturn. Uporaba verižnih klicev za isti primer bo videti, kot je prikazano spodaj.
when (mockDatabaseImpl.getGrade( anyInt ())).thenReturn('A').thenReturn('B').thenReturn('C');c) zaporedna vrnitev: Zadnji pristop je uporaba doReturn v okovani obliki, kot je navedeno zgoraj.
doReturn ('A').doReturn('B').doReturn('C').when(mockDatabaseImpl).getGrade( anyInt ())V # 12) Katere so različne vrste posmehljivih okvirov in kako delujejo?
Odgovor: Vrste Mocking framework-a in kako delujejo so razloženi spodaj.
Obstajata na splošno 2 kategoriji posmehljivih okvirov:
- Na osnovi posredniškega strežnika - Primer, Mockito, EasyMock itd.
- Na osnovi bajtkode - Primer, PowerMock, JMockit itd.
Primerjajmo oba okvira za različne parametre.
| Na osnovi posredniškega strežnika | Na osnovi bajtkode | |
|---|---|---|
| Preprosto | Preprostejši in enostavnejši za uporabo | Lahko vključuje zapleteno ponarejeno logiko |
| Način ustvarjanja | Ustvari se proxy ali lažni objekt, ki dejansko ne zahteva primerka razreda / vmesnika | V bistvu vključuje ustvarjanje predmetov in med izvajanjem manipulira s primerki za zasmehovano / zakrknjeno vedenje |
| Funkcionalnost | Posmehljivi razredi in vmesniki | Poleg razredov in vmesnikov omogoča posmehovanje statičnim metodam, končnim razredom itd |
| Odvisnost od Jave | Ni zelo tesno povezan z različicami Java | Ker ti okviri vključujejo manipulacijo bajt kod, so tesno povezani in morda niso združljivi nazaj / naprej v različicah java. |
| Primeri | Mockito, EasyMock itd. | PowerMock, JMockit itd. |
Zaključek
Vsebina, zajeta v tem članku, služi osnovnim razpravam o Mocking okvirih in zlasti pripravi Mockito intervjuja.
Poleg teoretičnega razumevanja zajetih vprašanj bi morali poskusiti tudi z resničnimi primeri kode, ki naredijo učenje teh okvirov bolj zabavno in zanimivo.
Upam, da ste uživali v celotni paleti vadnic v tej seriji Mockito.
Srečno učenje.
Priporočeno branje
- Vprašanja in odgovori za intervju
- Vadnica za Mockito: Mockito Framework za posmeh pri preskušanju enot
- Nekaj zanimivih vprašanj za preskušanje programske opreme
- Vprašanja in odgovori za preizkušanje ETL
- Najpogostejša vprašanja o intervjujih za obrazce in poročila Oracle
- Programska oprema Ročno preizkušanje Vprašanja za intervjuje za izkušene strokovnjake
- Najpogostejša tehnična vprašanja o Oracle Apps in Oracle SOA Intervju
- 25 najboljših vprašanj in odgovorov za intervju z agilnim testiranjem