Top 12 Mockito-interviewvragen (Mocking Framework-interview)

top 12 mockito interview questions

Meest gestelde Mockito-interviewvragen om het Mockito Mocking-interview te kraken:

In onze vorige tutorial hebben we geleerd Privé, statische en ongeldige methoden van bespotten ​ Lees het volledige trainingshandleidingen over Mockito voor een duidelijk begrip van het Mockito-framework.

Dit artikel behandelt de meest gestelde typische interviewvragen over het Mockito Mocking-framework.

Elke ontwikkelaar of QA wordt geacht de basisprincipes van Mocking te kennen om met gemak de meeste white box-tests (of unit-tests) te schrijven en de afhankelijkheden te bespotten voor verbeterde codedekking en meer vertrouwen in de applicatie.

Meest populaire Mockito-interviewvragen met gedetailleerde antwoorden

Hieronder staan ​​de meest gestelde vragen over Mocking Frameworks vermeld.

V # 1) Waarom hebben we spot nodig?

Antwoord: Er zijn veel use-cases van spot die helpen bij het testen van eenheden van de code onder isolatie en die de test zeer herhaalbaar en voorspelbaar maken.

Mocking is over het algemeen vereist wanneer:

naar) De te testen component heeft afhankelijkheden die nog niet zijn geïmplementeerd of de implementatie is aan de gang.

Een goed voorbeeld kan een REST API-eindpunt zijn dat later op een bepaald moment beschikbaar zal zijn, maar je hebt het via een afhankelijkheid in de code gebruikt.

Nu de echte implementatie nog steeds niet beschikbaar is, weet u meestal echt wat de verwachte respons van die API is. Met Mocks kunt u dat soort integratie testen.

b) Component werkt de status in het systeem bij.

Voorbeeld: DB-oproepen - u zou uw database niet willen bijwerken met gegevens die alleen voor testdoeleinden zijn bedoeld. Dit kan resulteren in het beschadigen van de gegevens, bovendien is de beschikbaarheid van DB een andere uitdaging wanneer de test wordt uitgevoerd.

Om dergelijk gedrag te vermijden, kunnen DB-oproepen worden bespot in het te testen onderdeel. Daarom is er geen directe koppeling tussen DB en het te testen onderdeel.

Q # 2) Verschil tussen doReturn en thenReturn.

Antwoord: Mockito biedt twee verschillende syntaxis voor het maken van stubs, zoals:

• doReturn en danReturn
• doe niets (niet dan niets)
• doThrow en dan Throw

Beide methoden stellen stubs in en kunnen worden gebruikt om stubs te maken / in te stellen en kunnen soms door elkaar worden gebruikt.

implementeren binaire zoekboom in java

Dus hoe verschillen deze beide?

naar) De thenReturn-manier van stubben is een type-veilige manier om stubs te maken. Wat dit in wezen betekent, is dat het een compilatiecontrole uitvoert op de retourtypen die u ook wilt stubben.

Laten we dit begrijpen met een voorbeeld:

Ga uit van een methode getItemDetails Aan bespotItemService die een object van het type retourneert ItemSku. Dus met dan terug, je zult niets anders kunnen retourneren dan het type ItemSku, maar met doReturn kun je de stub instellen om iets te retourneren en de test zal mislukken (of een uitzondering genereren) tijdens de uitvoering.

// werkt

// gooit een uitzondering voor de compilatietijd

// met doReturn werkt zowel de stub-setup als het niet veilig is om te compileren.

// hier proberen we een object van het type double terug te geven dat nog steeds werkt en geen waarschuwing voor compilatietijd genereert.

b) Een ander belangrijk verschil tussen deze 2 manieren om de stub te maken is voor Mocked-objecten, afgezien van compileerveiligheid is er niet veel verschil.

Voor bespioneerde objecten zal de 'thenReturn' -achtige stub-instelling echter niet werken, omdat het zal resulteren in het aanroepen van de echte methode voordat het stubbed antwoord is terug te geven als de aanroep en niet op een Mock, maar op Spy die een echte objectinstantie omhult .

Dus stel dat er een spion wordt genoemd spiedObject en het heeft een methode testMethod die een geheel getal retourneert, en om een ​​stub hierop in te stellen, moet je doReturn gebruiken in plaats van thenReturn.

V # 3) Wanneer en waarom moet een spion worden gebruikt?

Antwoord: Spy is een soort gedeeltelijke mock die wordt ondersteund door Mockito.

Dit betekent in wezen dat het een soort instantie is waarbij:

naar) Als er geen mock is opgezet, resulteert elke interactie op spionage in het aanroepen van de echte methoden. Maar het stelt je nog steeds in staat om de interacties met het bespioneerde object te verifiëren, zoals - werd een methode daadwerkelijk aangeroepen, hoe vaak de methode werd aangeroepen, wat waren de argumenten waarmee de methode werd aangeroepen enz.

b) Het geeft je de flexibiliteit om gedeeltelijke spotjes op te zetten.

Bijvoorbeeld, als je een object hebt met 2 methoden - methode1 en methode2 en je wilt dat methode1 wordt aangeroepen en methode2 wordt bespot. Spionnen bieden dit soort instellingen.

Het verschil tussen een mock en een stub in eenvoudige bewoordingen is dus: een mock wordt gemaakt van een type en niet van een instantie, terwijl een stub een feitelijke instantie van het class-object omhult.

V # 4) Waarom kunnen statische methoden niet worden bespot met Mockito?

Japan VPN free

Antwoord: Statische methoden zijn gekoppeld aan de klasse zelf en niet aan een bepaald exemplaar van de klasse. Dit betekent dat alle instanties / objecten van de klasse dezelfde instantie van de statische methode gebruiken.

Statische methoden lijken meer op procedurele code en worden meestal gebruikt in oudere systemen in het algemeen.

Mock-bibliotheken creëren meestal nep-kaders door dynamische aanmaak van instanties tijdens runtime, hetzij via interfaces of via overerving, en aangezien de statische methode niet aan een bepaalde instantie is gekoppeld, is het niet mogelijk om mock-frameworks (zoals mockito, easy mock, enz.) Te bespotten om statische methoden te bespotten.

Frameworks zoals PowerMock die wel ondersteuning bieden voor statische methoden, voeren bytecode-manipulatie uit tijdens runtime om statische methoden te bespotten.

V # 5) Wat is de noodzaak om te verifiëren dat de mock werd genoemd?

Antwoord: Het opzetten van een stub op een bespot object (of een bespioneerde instantie) garandeert niet of de stubbed setup zelfs werd aangeroepen.

'Verificatie' -matchers, geef een faciliteit om te valideren of de stub die was opgezet daadwerkelijk is aangeroepen of niet, hoe vaak de aanroep is gedaan, met welke argumenten de stubbed-methode werd aangeroepen, enz.

In wezen stelt het ons in staat om de testopstelling en het verwachte resultaat op een robuustere manier te verifiëren.

V # 6) Wat is een goede testbare code?

Antwoord:

Enkele punten over testbare code (wat betekent dat deze gemakkelijk kan worden getest) zijn:

• Minder afhankelijkheden of strakke koppeling - Voorbeeld: Afhankelijkheden moeten worden geïnjecteerd in plaats van direct geïnstantieerd.
• Code die voldoet aan SRP (Single Responsibility Principle) - Dit betekent in wezen dat de klasse niet meerdere redenen moet hebben om te veranderen. Het naleven van SRP voorkomt dat klassen afhankelijkheid van zichzelf creëren en houdt de code samenhangend en schoon.
• Minder / minimaal gebruik van statische methoden en laatste klassen - Deze duiden meestal op code-geuren en werden meestal geassocieerd met de legacy-code.

V # 7) Wat zijn de beperkingen van Mockito?

Antwoord: Mockito is een voorkeursraamwerk voor de meeste op Java gebaseerde projecten. Het is gemakkelijk te implementeren, te lezen en te begrijpen.

Enkele van de nadelen of beperkingen in termen van functionaliteit zijn:

• Het onvermogen om statische methoden te bespotten.
• Constructeurs, privémethoden en laatste klassen kunnen niet worden bespot.

V # 8) Welke frameworks kunnen het bespotten van privé- en statische methoden ondersteunen?

Antwoord: Frameworks zoals PowerMockito (uitbreidingen van Mockito-framework), JMockit, enz. Bieden middelen om privé- en statische methoden te bespotten.

V # 9) Spottende / stubbing-standaardmethoden in Interface in Java 8.

wat is een wifi-beveiligingssleutel

Antwoord: Met de implementatie van standaardmethoden in Interface door Java 8, biedt Mockito kant-en-klare ondersteuning om dergelijke standaardmethoden te bespotten. (Houd er rekening mee dat deze ondersteuning werd geïntroduceerd vanaf Mockito 2).

Deze methoden kunnen worden bespot / afgestoten zoals elke andere methode van een klasse of interface.

V # 10) Hoe kan de volgorde van stub-aanroepen worden geverifieerd in Mockito?

Antwoord: Als je de volgorde wilt verifiëren waarin spotjes werden genoemd, is Mockito's ' In volgorde ”Interface kan worden gebruikt.

Tijdens de test hoeft u alleen maar een Inorder-object in te stellen / aan te maken, waarbij u een lijst met mock-objecten opslaat waarvan de volgorde van de mock-objecten moet worden bepaald (als er meerdere methoden op dezelfde mock zijn en er is geen andere mock die om geverifieerd te worden, is het voldoende om de bespotte klasse maar één keer te noemen).

Beschouw de onderstaande test die een object van InOrder definieert en 2 exemplaren van mockDatabaseImpl vermeldt

Ter referentie is het ook nuttig om de code van de te testen methode op te sommen om de volgorde van de testuitvoering te begrijpen:

Zoals hierboven te zien is, roept databaseImpl eerst updateScores aan en vervolgens getGrade.

Dus als u een unit-test schrijft met Mockito, hiervoor en u moet de volgorde van de aanroepen op databaseImpl controleren, raadpleeg dan de testcode en zorg ervoor dat de beweringen worden gedaan volgens de verwachte volgorde.

Als ik in het bovenstaande voorbeeld de volgorde van de beweringen verander, zal de test mislukken met uitzondering van 'VerificationInOrderFailure'.

Na het wijzigen van de assert-volgorde ziet de code er als volgt uit:

De bovenstaande testuitvoering genereert een uitzondering met het type:

'VerificationInOrderFailure' org.mockito.exceptions.verification.VerificationInOrderFailure:
Verificatie bij mislukking van de bestelling
Gezocht maar niet ingeroepen:
mockDatabaseImpl.updateScores (
isA (java.lang.String),
isA (java.lang.Integer)

V # 11) Retourneren van meerdere waarden voor opeenvolgende methodeaanroepen

Antwoord: Om verschillende waarden te retourneren voor meerdere aanroepen van dezelfde stubbed-methode, biedt Mockito 3 benaderingen zoals hieronder weergegeven:

naar) Door komma's gescheiden gebruiken: Dit werkt met thenReturn.

Bijvoorbeeld Laten we, door het bovenstaande codevoorbeeld te nemen, proberen om opeenvolgende stub in te stellen voor methode - getGrade die verschillende waarden zal retourneren, afhankelijk van de volgorde van iteraties:

Dit betekent dat wanneer getGrade-methoden worden aangeroepen in de methode die wordt getest, de eerste aanroep 'A' retourneert, de tweede aanroep 'B', enzovoort.

b) Opeenvolgend danRetour: Dit is een aanpak die is geketend met thenReturn-statements. Het toepassen van gekoppelde oproepen op hetzelfde voorbeeld ziet eruit zoals hieronder weergegeven.

c) Opeenvolgende doReturn: De laatste benadering is het gebruik van doReturn in het geketende formaat zoals hierboven.

Vraag 12) Wat zijn de verschillende soorten mocking-frameworks en hoe werken ze?

Antwoord: Typen van het bespottingsraamwerk en hoe ze werken, worden hieronder uitgelegd.

Er zijn grofweg 2 categorieën spottende kaders:

1. Proxy-gebaseerd ​ Voorbeeld, Mockito, EasyMock, enz.
2. Bytecode gebaseerd ​ Voorbeeld, PowerMock, JMockit, enz.

Laten we beide kaders op verschillende parameters vergelijken.

Gevolgtrekking

De inhoud die in dit artikel wordt behandeld, is bedoeld voor basisdiscussies over mocking-frameworks en specifiek voor Mockito-interviewvoorbereiding.

Naast het verkrijgen van een theoretisch begrip van de behandelde vragen, zou men ook moeten proberen om echte codevoorbeelden te doen die het leren van deze frameworks leuker en interessanter maken.

Hoop, je hebt genoten van het hele scala aan tutorials in deze Mockito-serie.

Veel plezier met leren.

PREV-zelfstudie ​ EERSTE Tutorial

Aanbevolen literatuur

• Interview vragen en antwoorden
• Mockito-zelfstudie: Mockito-raamwerk voor bespotten bij het testen van eenheden
• Enkele interessante sollicitatievragen voor het testen van software
• Vragen en antwoorden over ETL-tests
• Top Oracle Forms and Reports Interviewvragen
• Software Manual Testing Interviewvragen voor ervaren professionals
• Top Oracle Apps technische en Oracle SOA sollicitatievragen
• 25 Beste Agile Testing Interview Vragen en Antwoorden