top 12 mockito interview questions
De vanligaste Mockito-intervjufrågorna för att knäcka Mockito-mockingintervjun:
I vår tidigare handledning lärde vi oss Privata, statiska och ogiltiga metoder för hån . Läs igenom kompletta utbildningsövningar om Mockito för en tydlig förståelse av Mockito-ramverket.
Den här artikeln täcker de vanligaste vanliga intervjufrågorna om Mockito Mocking-ramverket.
Varje utvecklare eller QA förväntas kunna Mocking-grunderna för att enkelt kunna skriva de flesta vita rutorna (eller enhetstester) och att håna beroenden för förbättrad kodtäckning och större förtroende för applikationen.
Mest populära Mockito-intervjufrågor med detaljerade svar
Nedan listas de vanligaste frågorna om Mocking Frameworks.
F # 1) Varför behöver vi hån?
Svar: Det finns många användningsfall av hån som hjälper till vid enhetstestning av koden under isolering och gör testet mycket repeterbart och förutsägbart.
Spott krävs vanligtvis när:
till) Komponenten som testas har beroenden som ännu inte är implementerade eller implementeringen pågår.
Ett bra exempel kan vara en REST API-slutpunkt som kommer att finnas tillgänglig senare vid någon tidpunkt, men du har konsumerat den i koden via ett beroende.
Nu eftersom den verkliga implementeringen fortfarande inte är tillgänglig, vet du för det mesta vad som är det förväntade svaret för det API: et. Mocks låter dig testa den typen av integration.
b) Komponent uppdaterar tillståndet i systemet.
Exempel: DB-samtal - du vill inte uppdatera din DB med data som bara är för teständamål. Detta kan leda till att data skadas, dessutom är tillgängligheten av DB en annan utmaning när testet körs.
För att undvika sådant beteende kan DB-samtal hånas i komponenten som testas. Därför finns det ingen direkt koppling av DB och komponenten som testas.
F # 2) Skillnad mellan doReturn och sedanReturn.
Svar: Mockito tillhandahåller två olika syntaxer för att skapa stubbar som:
- doReturn och sedanReturn
- gör ingenting (inte då ingenting)
- gör och sedan kast
Båda dessa metoder ställer in stubbar och kan användas för att skapa / ställa in stubbar och kan ibland användas omväxlande.
qa manager intervju frågor och svar
Så hur skiljer sig båda dessa?
till) Då Retur-sättet för stubbning är ett typsäkert sätt att sätta upp stubbar. Vad detta i huvudsak betyder är att det gör en kompileringstidskontroll mot de returtyper som du också vill stubba.
Låt oss förstå detta med ett exempel:
Antag en metod getItemDetails på mockedItemService som returnerar ett objekt av typen ItemSku. Så med sedan Återgå, du kommer inte att kunna returnera något annat än av typen ItemSku men med doReturn kan du ställa in stubben för att returnera någonting och testet misslyckas (eller kastar ett undantag) under körningen.
// Arbetar
when (mockedItemService.getItemDetails(123)).thenReturn(new ItemSku());// kastar kompileringstidundantag
when (mockedItemService.getItemDetails(123)).thenReturn(expectedPrice);// med doReturn fungerar både stubkonfigurationen eftersom den inte är kompilerad.
// här försöker vi returnera ett objekt av typen dubbel som fortfarande fungerar och inte kastar någon kompileringsvarning.
doReturn (expectedPrice).when(mockedItemService.getItemDetails(123)); doReturn (new ItemSku()).when(mockedItemService.getItemDetails(123));b) En annan viktig skillnad mellan dessa två sätt att stubben är för hånade objekt, förutom kompileringssäkerhet är det inte mycket skillnad.
Men för spionerade objekt kommer 'thenReturn' typ av stub-installation inte att fungera, eftersom det kommer att resultera i att den riktiga metoden anropas innan det stubbed-svaret returneras som samtalet och inte på en Mock, men på Spy som slår in en verklig objektinstans .
Tänk, det finns en spion som heter spiedObject och den har en metod testMethod som returnerar ett heltal, för att ställa in en stub på detta måste du använda doReturn istället för thenReturn.
doReturn (10).when(spiedObject.testMethod());F # 3) När och varför ska en spion användas?
Svar: Spy är en typ av partiell mock som stöds av Mockito.
Detta betyder i huvudsak är en typ av exempel där:
till) När ingen mock är inställd resulterar all interaktion på spion i att kalla de riktiga metoderna. Men det låter dig fortfarande verifiera interaktionerna med det spionerade objektet som - var en metod som faktiskt kallades, hur många gånger metoden anropades, vad var argumenten som metoden kallades etc.
b) Det ger dig flexibiliteten att ställa in partiella mocks.
Till exempel, om du har ett objekt med två metoder - metod1 och metod2 och du vill att metod1 ska anropas och metod2 ska hånas. Spioner tillhandahåller den här typen av inställningar.
Så skillnaden mellan en mock och en stub i enkla termer är - en mock skapas från en typ och inte från en instans medan en stub sveper en faktisk instans av klassobjektet.
F # 4) Varför kan inte statiska metoder hånas med Mockito?
cirkulär länkad lista c ++
Svar: Statiska metoder är associerade med själva klassen och inte någon speciell förekomst av klassen. Detta innebär att alla instanser / objekt i klassen använder samma instans av den statiska metoden.
Statiska metoder liknar mer procedurkod och används mest i äldre system i allmänhet.
Mock-bibliotek skapar vanligtvis mocks genom att skapa dynamisk förekomst vid körning, antingen via gränssnitt eller genom arv och eftersom den statiska metoden inte är associerad med någon speciell instans är det inte möjligt för hånande ramar (som mockito, lätt mock, etc.) att håna statiska metoder.
Ramar som PowerMock som har stöd för statiska metoder utför bytecode-manipulation vid körning för att håna statiska metoder.
F # 5) Vad är behovet av att verifiera att mocken anropades?
Svar: Att ställa in en stub på ett hånat objekt (eller en spionerad instans) garanterar inte om den stubbade installationen ens anropades.
”Verifiering” matchare, ge en möjlighet att validera om stubben som sattes upp faktiskt åberopades eller inte, hur många gånger ringde samtalet, vilka argument kallades den stubbade metoden etc.
I grund och botten tillåter det oss att verifiera testinställningarna och det förväntade resultatet på ett mer robust sätt.
F # 6) Vad är en bra testbar kod?
Svar:
Få punkter om testbar kod (vilket betyder att det enkelt kan testas enhet) inkluderar:
- Minskat antal beroenden eller snäva kopplingar - Exempel: Beroenden bör injiceras snarare än direkta.
- Kod som följer SRP (Single Responsibility Principle) - Detta betyder i huvudsak att klassen inte ska ha flera skäl att ändra. Genom att följa SRP undviks klasser som skapar beroende av sig själv och håller koden sammanhängande och ren.
- Mindre / minimal användning av statiska metoder och slutklasser - Dessa indikerar generellt kodluktar och var mestadels associerade med den äldre koden.
F # 7) Vilka begränsningar har Mockito?
Svar: Mockito är ett valfritt ramverk för de flesta java-baserade projekt. Det är enkelt att implementera, läsa och förstå.
Några av nackdelarna eller begränsningarna när det gäller funktionalitet är:
- Dess oförmåga att håna statiska metoder.
- Konstruktörer, privata metoder och slutklasser kan inte hånas.
F # 8) Vilka ramar kan stödja håna privata och statiska metoder?
Svar: Ramar som PowerMockito (förlängningar av Mockito framework), JMockit, etc. ger medel för att håna privata och statiska metoder.
F # 9) Mocking / Stubbing standardmetoder i gränssnitt i Java 8.
Svar: Med Java 8: s implementering av standardmetoder i Interface tillhandahåller Mockito out-of-box-stöd för att håna sådana standardmetoder. (Observera att detta stöd introducerades från Mockito 2 och framåt).
Dessa metoder kan hånas / stubbas som alla andra metoder i en klass eller gränssnitt.
F # 10) Hur kan beställning av stubbeinbjudningar verifieras i Mockito?
Svar: När du vill verifiera i vilken ordning mockar anropades, är Mockitos ' I ordning ”Gränssnitt kan användas.
Under testet måste du helt enkelt ställa in / skapa ett Inorder-objekt och lista ner en lista över mock-objekt som mockens ordning måste fastställas på (om det finns flera metoder på samma mock och det inte finns någon annan mock som behöver för att verifieras är det tillräckligt att bara nämna den hånade klassen en gång).
Tänk på testet nedan som definierar ett objekt av InOrder och nämner 2 förekomster 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 referens kan listning av koden för den metod som testas vara till hjälp för att förstå ordningen för testutförande:
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 framgår ovan, anropar databaseImpl först updateScores och sedan samtal getGrade.
Så om du skriver ett enhetstest med Mockito, för detta och du måste säkerställa ordningen på samtalen på databaseImpl, se testkoden och se till att påståendena görs enligt den förväntade beställningen.
I exemplet ovan om jag ändrar ordningen på asserts, kommer det att få testet att misslyckas med undantag för “VerificationInOrderFailure”.
Efter att ha ändrat påstående ordning ser koden ut som nedan:
@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()); } Ovanstående testkörning ger ett undantag med typ:
“VerificationInOrderFailure” org.mockito.exceptions.verification.VerificationInOrderFailure:
Verifiering i ordningsfel
Sökt men inte åberopat:
mockDatabaseImpl.updateScores (
isA (java.lang.String),
isA (java.lang.Integer)
F # 11) Returnerar flera värden mot på varandra följande metodanrop
Svar: För att returnera olika värden för flera anrop av samma stubbed-metod ger Mockito tre tillvägagångssätt enligt nedan:
till) Använda kommaseparerad: Detta fungerar med thenReturn.
Till exempel tar vi ovanstående kodprov, låt oss försöka ställa in på varandra följande stub för metod - getGrade som returnerar olika värden beroende på sekvensen av iterationer:
when (mockDatabaseImpl.getGrade( anyInt ())).thenReturn('A','B', 'C');Det betyder att när getGrade-metoder kallas in i metoden som testas kommer den första anropet att returnera 'A', den andra anropet kommer att returnera 'B' och så vidare.
b) Efter varandra sedan Återgå: Detta är ett tillvägagångssätt som är kedjat med sedanReturn uttalanden. Att använda kedjade samtal till samma exempel ser ut som nedan.
when (mockDatabaseImpl.getGrade( anyInt ())).thenReturn('A').thenReturn('B').thenReturn('C');c) På varandra följande doReturn: Det sista tillvägagångssättet är att använda doReturn i det kedjade formatet som ovan.
var kan jag titta på anime gratis online
doReturn ('A').doReturn('B').doReturn('C').when(mockDatabaseImpl).getGrade( anyInt ())F # 12) Vilka är de olika typerna av spottande ramar och hur fungerar de?
Svar: Typer av Mocking-ramverk och hur de fungerar förklaras nedan.
Det finns i stort sett två kategorier av spottande ramar:
- Proxybaserad - Exempel, Mockito, EasyMock, etc.
- Bytecode baserad - Exempel, PowerMock, JMockit, etc.
Låt oss jämföra båda dessa ramar med olika parametrar.
| Proxybaserad | Bytecode baserad | |
|---|---|---|
| Enkelt | Mer enkelt och lättanvänt | Kan innebära komplex logik för mock-installation |
| Skapande | En proxy eller falskt objekt som inte egentligen kräver förekomst av klass / gränssnitt skapas | Det handlar i huvudsak om att skapa objekt och vid körning manipulerar instanserna för det hånade / stubbade beteendet |
| Funktionalitet | Spottande klasser och gränssnitt | Förutom klasser och gränssnitt, tillåter spottande statiska metoder, slutklasser etc. |
| Java-beroende | Inte särskilt tätt kopplade till Java-versioner | Eftersom dessa ramar involverar bytkodmanipulation är de tätt kopplade och kanske inte bakåt / framåtkompatibla över Java-versioner. |
| Exempel | Mockito, EasyMock etc. | PowerMock, JMockit etc. |
Slutsats
Innehållet som omfattas av den här artikeln serverar grundläggande diskussioner kring Mocking-ramar och särskilt förberedelse av Mockito-intervjuer.
Förutom att få en teoretisk förståelse för de frågor som behandlas, bör man också försöka göra riktiga kodexempel som gör att lära sig dessa ramar roligare och intressantare.
Hoppas, du gillade hela utbudet av handledning i denna Mockito-serie.
Lyckligt lärande.
PREV-handledning | FÖRSTA självstudier
Rekommenderad läsning
- Intervjufrågor och svar
- Mockito Tutorial: Mockito Framework for Mocking in Unit Testing
- Några intressanta programtestintervjufrågor
- ETL Testing Intervju Frågor och svar
- De viktigaste frågorna om Oracle Forms and Reports
- Programvaruhandbok Testning av intervjufrågor för erfarna yrkesverksamma
- Topp Oracle Apps tekniska och Oracle SOA intervjufrågor
- 25 bästa intervjuer och svar på Agile Testing