top 12 mockito interview questions
Cele mai frecvente întrebări ale interviului Mockito pentru a sparge interviul batjocoritor Mockito:
În tutorialul nostru anterior, am învățat Metode private, statice și vid de batjocură . Citiți prin tutoriale complete de formare pe Mockito pentru o înțelegere clară a cadrului Mockito.
Acest articol acoperă cele mai frecvente întrebări tipice de interviu despre cadrul Mockito Mocking.
Se așteaptă ca fiecare dezvoltator sau QA să cunoască elementele de bază ale jocurilor de joc pentru a scrie cu ușurință cele mai multe teste ale casetei albe (sau teste unitare) și pentru a bate joc de dependențe pentru o acoperire îmbunătățită a codului și o mai mare încredere în aplicație.
Cele mai populare întrebări de interviu Mockito cu răspunsuri detaliate
Mai jos sunt enumerate cele mai frecvente întrebări despre Mocking Frameworks.
Q # 1) De ce avem nevoie de batjocură?
Răspuns: Există o mulțime de cazuri de utilizare a batjocurii care ajută la testarea unitară a codului sub izolare și fac testul extrem de repetabil și previzibil.
Batjocura este în general necesară atunci când:
la) Componenta testată are dependențe care nu sunt încă implementate sau implementarea este în desfășurare.
Un bun exemplu poate fi un punct final REST API care va fi disponibil mai târziu la un moment dat, dar l-ați consumat în cod printr-o dependență.
Acum, deoarece implementarea reală nu este încă disponibilă, știți de cele mai multe ori care este răspunsul așteptat al acelui API. Mockurile vă permit să testați aceste tipuri de integrare.
b) Componenta actualizează starea din sistem.
Exemplu: Apeluri DB - nu ați dori să vă actualizați DB-ul cu date care sunt doar pentru testare. Acest lucru ar putea duce la coruperea datelor, în plus, disponibilitatea DB este o altă provocare atunci când testul este executat.
Astfel, pentru a evita un astfel de comportament, apelurile DB ar putea fi batjocorite în componenta testată. Prin urmare, nu există o cuplare directă a DB și a componentei testate.
Q # 2) Diferența dintre doReturn și apoi Return.
Răspuns: Mockito oferă două sintaxi diferite pentru crearea de butoane, cum ar fi:
- doReturn și apoiReturn
- nu face nimic (nu atunci nimic)
- doThrow și apoiThrow
Ambele metode de configurare pot fi utilizate și pot fi utilizate pentru a crea / configura butoane și pot fi folosite în mod alternativ uneori.
downloader mp3 ușor descărcare gratuită versiune completă
Deci, în ce fel diferă ambele?
la) Modul de retragere thenReturn este un mod sigur de configurare a tipurilor. Ceea ce înseamnă în esență acest lucru este că face o verificare în timp de compilare față de tipurile de returnare pe care doriți să le stub și.
Să înțelegem acest lucru cu un exemplu:
Să presupunem o metodă getItemDetails pe mockedItemService care returnează un obiect de tip ItemSku. Deci cu apoi Reveniți, nu veți putea returna altceva în afară de tipul ItemSku, dar cu doReturn, puteți configura butonul pentru a returna orice și testul va eșua (sau va arunca o excepție) în timpul execuției.
// lucrări
when (mockedItemService.getItemDetails(123)).thenReturn(new ItemSku());// aruncă o excepție de timp de compilare
when (mockedItemService.getItemDetails(123)).thenReturn(expectedPrice);// cu doReturn, atât configurația stub funcționează, deoarece nu este sigură la compilare.
// aici încercăm să returnăm un obiect de tip double care încă funcționează și nu lansează niciun avertisment de timp de compilare.
doReturn (expectedPrice).when(mockedItemService.getItemDetails(123)); doReturn (new ItemSku()).when(mockedItemService.getItemDetails(123));b) O altă diferență importantă între aceste 2 căi către butuc este pentru obiectele batjocorite, în afară de siguranța la compilare, nu există prea multe diferențe.
Cu toate acestea, pentru obiectele Spied, tipul de setare „thenReturn” nu va funcționa, deoarece va rezulta în apelarea metodei reale înainte ca răspunsul împiedicat să revină ca apel și nu pe un Mock, ci pe Spy care împachetează o instanță de obiect reală .
Să presupunem că există un spion numit spiedObject și are o metodă testMethod care returnează un număr întreg, apoi pentru a configura un stub pe aceasta va trebui să utilizați doReturn în loc de thenReturn.
doReturn (10).when(spiedObject.testMethod());Î. 3) Când și de ce ar trebui folosit un spion?
Răspuns: Spionul este un tip de batjocură parțială acceptată de Mockito.
Acest lucru înseamnă, în esență, că este un tip de instanță în care:
la) Când nu este configurată nicio batjocură, orice interacțiune cu spionul are ca rezultat apelarea metodelor reale. Dar vă permite totuși să verificați interacțiunile cu obiectul spion, cum ar fi - a fost de fapt o metodă numită, de câte ori a fost apelată metoda, care au fost argumentele care au folosit metoda etc.
b) Vă oferă flexibilitatea de a configura jocuri parțiale.
De exemplu, dacă aveți un obiect cu 2 metode - metoda1 și metoda2 și doriți ca metoda1 să fie apelată și metoda2 să fie batjocorită. Spionii oferă acest tip de configurare.
Deci, diferența dintre o batjocură și un butuc în termeni simpli este - o batjocură este creată dintr-un tip și nu dintr-o instanță, în timp ce un butuc înfășoară o instanță reală a obiectului clasei.
Q # 4) De ce nu pot fi batjocorite metodele statice folosind Mockito?
listă circulară legată c ++
Răspuns: Metodele statice sunt asociate cu clasa în sine și nu cu nicio instanță particulară a clasei. Aceasta înseamnă că toate instanțele / obiectele clasei utilizează aceeași instanță a metodei statice.
Metodele statice seamănă mai mult cu codul procedural și sunt utilizate mai ales în sistemele vechi în general.
Bibliotecile simulate creează în mod obișnuit simulări prin crearea instanțelor dinamice la rulare, fie prin interfețe, fie prin moștenire și întrucât metoda statică nu este asociată cu nicio instanță specială, nu este posibil ca cadrele de batjocură (cum ar fi mockito, easy mock etc.) să batjocorească metodele statice.
Cadrele precum PowerMock care au suport pentru metodele statice efectuează manipularea codului bytec în timpul rulării pentru a bate joc de metodele statice.
Q # 5) Care este nevoia de a verifica dacă s-a apelat simulatorul?
Răspuns: Configurarea unui stub pe un obiect batjocorit (sau o instanță spionată) nu garantează dacă configurarea stubbed a fost chiar invocată.
Potrivitori de „verificare”, dați o facilitate pentru a valida dacă stub-ul care a fost configurat a fost efectiv invocat sau nu, de câte ori a fost făcut apelul, cu ce argumente s-a apelat metoda stubbed etc.
În esență, ne permite să verificăm configurarea testului și rezultatul scontat într-un mod mai robust.
Q # 6) Ce este un cod bun testabil?
Răspuns:
Câteva puncte despre codul testabil (adică care ar putea fi testat cu ușurință în unitate) includ:
- Număr redus de dependențe sau cuplare strânsă - Exemplu: Dependențele ar trebui injectate mai degrabă decât instanțiate direct.
- Cod care respectă SRP (Principiul unic de responsabilitate) - Aceasta înseamnă în esență că clasa nu ar trebui să aibă mai multe motive pentru a se schimba. Aderarea la SRP evită clasele care creează dependență de sine și păstrează codul coeziv și curat.
- Utilizare mai mică / minimă a metodelor statice și a claselor finale - Acestea indică, în general, mirosuri de cod și au fost în mare parte asociate cu codul vechi.
Q # 7) Care sunt limitările Mockito?
Răspuns: Mockito este un cadru de alegere pentru majoritatea proiectelor bazate pe Java. Este ușor de implementat, citit și înțeles.
Unele dintre dezavantaje sau limitări în ceea ce privește funcționalitatea sunt:
- Incapacitatea sa de a batjocori metodele statice.
- Constructorii, metodele private și clasele finale nu pot fi batjocorite.
Q # 8) Ce cadre pot sprijini batjocorirea metodelor private și statice?
Răspuns: Cadrele precum PowerMockito (extensii ale cadrului Mockito), JMockit etc. oferă mijloace de a batjocori metode private și statice.
Q # 9) Metode implicite de batjocură / stubing în interfață în Java 8.
Răspuns: Odată cu implementarea de către Java 8 a metodelor implicite în interfață, Mockito oferă asistență directă pentru a batjocori astfel de metode implicite. (Vă rugăm să rețineți că acest suport a fost introdus de la Mockito 2 și mai departe).
Aceste metode pot fi batjocorite / împiedicate ca orice alte metode ale unei clase sau interfețe.
Q # 10) Cum poate fi verificată ordinea invocărilor stub în Mockito?
Răspuns: Când doriți să verificați ordinea în care au fost apelate batjocurile, „ În ordine ”Se poate utiliza interfața.
cum se creează o matrice de șiruri java
În timpul testului, trebuie pur și simplu să configurați / creați un obiect Inorder, listând o listă de obiecte simulate pe care trebuie să se stabilească ordinea simulărilor (dacă există mai multe metode pe aceeași simulare și nu există nici o altă simulare care să aibă nevoie de pentru a fi verificat atunci este suficient să menționăm clasa batjocorită o singură dată).
Luați în considerare testul dat mai jos, care definește un obiect din InOrder și menționează 2 apariții ale 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()); } De asemenea, pentru referință, enumerarea codului metodei testate va fi utilă pentru a înțelege ordinea executării testului:
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); }După cum s-a văzut mai sus, databaseImpl apelează mai întâi updateScores și apoi apelează getGrade.
Deci, dacă scrieți un test unitar folosind Mockito, pentru aceasta și trebuie să asigurați ordinea apelurilor pe databaseImpl, consultați codul de testare și asigurați-vă că afirmațiile sunt făcute conform comenzii așteptate.
În exemplul de mai sus, dacă schimb ordinea afirmărilor, atunci va provoca eșecul testului, cu excepția „VerificationInOrderFailure”.
După modificarea ordinii de afirmare, codul arată așa cum se arată mai jos:
@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()); } Execuția testului de mai sus aruncă o excepție cu tipul:
„VerificationInOrderFailure” org.mockito.exceptions.verification.VerificationInOrderFailure:
Verificare în caz de eșec
Dorit, dar nu invocat:
mockDatabaseImpl.updateScores (
isA (java.lang.String),
isA (java.lang.Integer)
Q # 11) Returnarea valorilor multiple împotriva apelurilor consecutive de metodă
Răspuns: Pentru a returna valori diferite pentru invocații multiple ale aceleiași metode stubbed, Mockito oferă 3 abordări după cum se arată mai jos:
la) Folosind virgulă separată: Acest lucru funcționează cu thenReturn.
De exemplu , luând exemplul de cod de mai sus, să încercăm să configurăm stubul consecutiv pentru metoda - getGrade care va returna valori diferite în funcție de secvența iterațiilor:
when (mockDatabaseImpl.getGrade( anyInt ())).thenReturn('A','B', 'C');Aceasta înseamnă că atunci când metodele getGrade sunt apelate în metoda testată, prima invocație va returna „A”, a doua invocare va returna „B” și așa mai departe.
b) Consecutiv apoi Întoarcere: Aceasta este o abordare care este înlănțuită cu declarațiile thenReturn. Aplicarea apelurilor înlănțuite la același exemplu va arăta așa cum se arată mai jos.
when (mockDatabaseImpl.getGrade( anyInt ())).thenReturn('A').thenReturn('B').thenReturn('C');c) Retur consecutiv: Ultima abordare este utilizarea doReturn în format înlănțuit ca mai sus.
doReturn ('A').doReturn('B').doReturn('C').when(mockDatabaseImpl).getGrade( anyInt ())Q # 12) Care sunt diferitele tipuri de cadre de batjocură și cum funcționează?
Răspuns: Tipurile cadrului de batjocură și cum funcționează sunt explicate mai jos.
Există în general 2 categorii de cadre de batjocură:
- Bazat pe proxy - Exemplu, Mockito, EasyMock etc.
- Bazat pe bytecode - Exemplu, PowerMock, JMockit etc.
Să comparăm aceste două cadre pe diferiți parametri.
| Bazat pe proxy | Bazat pe bytecode | |
|---|---|---|
| Simplit | Mai simplu și mai ușor de utilizat | Ar putea implica o logică complexă de configurare a simulării |
| Mod de creație | Se creează un proxy sau un obiect fals care nu necesită instanță de clasă / interfață | În esență, implică crearea de obiecte și, în timpul rulării, manipulează instanțele pentru comportamentul batjocorit / împiedicat |
| Funcționalitate | Clase și interfețe de batjocură | În plus față de clase și interfețe, permite batjocorirea metodelor statice, claselor finale etc. |
| Dependența Java | Nu foarte strâns cuplat la versiunile java | Deoarece aceste cadre implică manipularea codurilor de bytec, acestea sunt strâns cuplate și s-ar putea să nu fie compatibile înapoi / înainte în versiunile java. |
| Exemple | Mockito, EasyMock etc. | PowerMock, JMockit etc. |
Concluzie
Conținutul acoperit în acest articol servește discuții de bază despre cadrele Mocking și, în special, pregătirea interviului Mockito.
Pe lângă obținerea unei înțelegeri teoretice a întrebărilor acoperite, ar trebui să încercați să faceți exemple de coduri reale, ceea ce face ca învățarea acestor cadre să fie mai distractivă și mai interesantă.
Sper că v-ați bucurat de întreaga gamă de tutoriale din această serie Mockito.
Învățare fericită.
PREV Tutorial | PRIMUL Tutorial
Lectură recomandată
- Întrebări și răspunsuri la interviu
- Tutorial Mockito: Mockito Framework pentru batjocură în testarea unității
- Câteva întrebări interesante despre testarea software-ului
- Întrebări și răspunsuri la interviuri de testare ETL
- Cele mai importante întrebări despre interviu pentru formulare și rapoarte Oracle
- Software de testare manuală Întrebări de interviu pentru profesioniști experimentați
- Top Oracle Apps Technical and Oracle SOA Interview Questions
- Cele mai bune 25 de întrebări și răspunsuri de interviu pentru testarea agilă