Menü

Top 12 Fragen zum Mockito-Interview (Mocking Framework-Interview)

  • Haupt
  • Andere
  • Top 12 Fragen zum Mockito-Interview (Mocking Framework-Interview)

top 12 mockito interview questions

Versuchen Sie Unser Instrument, Um Probleme Zu Beseitigen

Am häufigsten gestellte Fragen zum Mockito-Interview, um das Mockito-Mocking-Interview zu knacken:

In unserem vorherigen Tutorial haben wir gelernt Private, statische und nichtige Verspottungsmethoden . Lesen Sie die Komplette Tutorials zu Mockito für ein klares Verständnis des Mockito-Frameworks.

Dieser Artikel behandelt die am häufigsten gestellten typischen Interviewfragen zum Mockito Mocking-Framework.

Von jedem Entwickler oder jeder Qualitätssicherung wird erwartet, dass er die Mocking-Grundlagen kennt, um die meisten White-Box-Tests (oder Unit-Tests) mühelos schreiben zu können und die Abhängigkeiten für eine verbesserte Codeabdeckung und ein größeres Vertrauen in die Anwendung zu verspotten.

Fragen zum Mockito-Interview

Die beliebtesten Fragen zu Mockito-Interviews mit detaillierten Antworten

Nachfolgend sind die am häufigsten gestellten Fragen zu Mocking Frameworks aufgeführt.

F # 1) Warum müssen wir uns verspotten?

Antworten: Es gibt viele Anwendungsfälle von Verspottungen, die beim Unit-Testen des Codes unter Isolation helfen und den Test in hohem Maße wiederholbar und vorhersehbar machen.

Spott ist im Allgemeinen erforderlich, wenn:

zu) Die zu testende Komponente weist Abhängigkeiten auf, die noch nicht implementiert sind oder deren Implementierung ausgeführt wird.

Ein gutes Beispiel kann ein REST-API-Endpunkt sein, der später zu einem bestimmten Zeitpunkt verfügbar sein wird, den Sie jedoch über eine Abhängigkeit im Code verwendet haben.

Da die eigentliche Implementierung immer noch nicht verfügbar ist, wissen Sie die meiste Zeit wirklich, wie die erwartete Antwort dieser API lautet. Mit Mocks können Sie diese Art der Integration testen.

b) Die Komponente aktualisiert den Status im System.

Beispiel: DB-Aufrufe - Sie möchten Ihre DB nicht mit Daten aktualisieren, die nur zu Testzwecken dienen. Dies kann zu einer Beschädigung der Daten führen. Darüber hinaus ist die Verfügbarkeit der Datenbank eine weitere Herausforderung, wenn der Test ausgeführt wird.

Um ein solches Verhalten zu vermeiden, könnten DB-Aufrufe in der zu testenden Komponente verspottet werden. Daher gibt es keine direkte Kopplung von DB und der zu testenden Komponente.

F # 2) Unterschied zwischen doReturn und thenReturn.

Antworten: Mockito bietet zwei verschiedene Syntaxen zum Erstellen von Stubs wie:

  • doReturn und thenReturn
  • nichts tun (nicht dann nichts)
  • doThrow und thenThrow

Beide Methoden richten Stubs ein und können zum Erstellen / Einrichten von Stubs verwendet werden und können manchmal austauschbar verwendet werden.

So erstellen Sie ein String-Array Java

Wie unterscheiden sich diese beiden?

zu) Die thenReturn-Methode zum Stubben ist eine typsichere Methode zum Einrichten von Stubs. Dies bedeutet im Wesentlichen, dass eine Überprüfung zur Kompilierungszeit anhand der Rückgabetypen durchgeführt wird, die Sie ebenfalls stubben möchten.

Lassen Sie uns dies anhand eines Beispiels verstehen:

Nehmen Sie eine Methode an getItemDetails auf mockedItemService Dies gibt ein Objekt vom Typ zurück ItemSku. Also mit dann zurück, Sie können nichts anderes als den Typ ItemSku zurückgeben, aber mit doReturn können Sie den Stub so einrichten, dass alles zurückgegeben wird, und der Test schlägt während der Ausführung fehl (oder löst eine Ausnahme aus).

// funktioniert

when (mockedItemService.getItemDetails(123)).thenReturn(new ItemSku());

// löst eine Ausnahme zur Kompilierungszeit aus

when (mockedItemService.getItemDetails(123)).thenReturn(expectedPrice);

// Mit doReturn funktionieren beide Stub-Setups, da sie nicht sicher kompiliert werden können.

// Hier versuchen wir, ein Objekt vom Typ double zurückzugeben, das immer noch funktioniert und keine Warnung zur Kompilierungszeit auslöst.

doReturn (expectedPrice).when(mockedItemService.getItemDetails(123)); doReturn (new ItemSku()).when(mockedItemService.getItemDetails(123));

b) Ein weiterer wichtiger Unterschied zwischen diesen beiden Wegen zum Stub besteht bei verspotteten Objekten. Abgesehen von der Kompilierungssicherheit gibt es keinen großen Unterschied.

Bei Spion-Objekten funktioniert die Stub-Einrichtung „thenReturn“ jedoch nicht, da die reale Methode aufgerufen wird, bevor die gestoppelte Antwort als Aufruf zurückgegeben wird, und nicht auf einem Mock, sondern auf Spy, der eine reale Objektinstanz umschließt .

Nehmen wir also an, es gibt einen Spion namens spiedObject und es hat eine Methode testMethod, die eine Ganzzahl zurückgibt. Um einen Stub darauf einzurichten, müssen Sie doReturn anstelle von thenReturn verwenden.

doReturn (10).when(spiedObject.testMethod());

F # 3) Wann und warum sollte ein Spion eingesetzt werden?

Antworten: Spy ist eine Art Teil-Mock, der von Mockito unterstützt wird.

Dies bedeutet im Wesentlichen, dass es sich um eine Art von Instanz handelt, in der:

zu) Wenn kein Mock eingerichtet ist, führt jede Interaktion mit Spion dazu, dass die realen Methoden aufgerufen werden. Sie können jedoch weiterhin die Interaktionen mit dem ausspionierten Objekt überprüfen, z. B. - wurde eine Methode tatsächlich aufgerufen, wie oft wurde die Methode aufgerufen, mit welchen Argumenten wurde die Methode aufgerufen usw.

b) Es gibt Ihnen die Flexibilität, Teilverspottungen einzurichten.

Zum Beispiel, Wenn Sie ein Objekt mit zwei Methoden haben - Methode1 und Methode2 und möchten, dass Methode1 aufgerufen und Methode2 verspottet wird. Spione bieten diese Art der Einrichtung.

Der Unterschied zwischen einem Mock und einem Stub in einfachen Worten ist also: Ein Mock wird aus einem Typ und nicht aus einer Instanz erstellt, während ein Stub eine tatsächliche Instanz des Klassenobjekts umschließt.

F # 4) Warum können statische Methoden mit Mockito nicht verspottet werden?

Beste VPN für Japan

Antworten: Statische Methoden sind der Klasse selbst zugeordnet und nicht einer bestimmten Instanz der Klasse. Dies bedeutet, dass alle Instanzen / Objekte der Klasse dieselbe Instanz der statischen Methode verwenden.

Statische Methoden ähneln eher prozeduralem Code und werden im Allgemeinen hauptsächlich in Legacy-Systemen verwendet.

Mock-Bibliotheken erstellen Mocks normalerweise durch dynamische Instanzerstellung zur Laufzeit, entweder über Schnittstellen oder durch Vererbung. Da die statische Methode keiner bestimmten Instanz zugeordnet ist, ist es nicht möglich, Frameworks (wie Mockito, Easy Mock usw.) zu verspotten, um statische Methoden zu verspotten.

Frameworks wie PowerMock, die statische Methoden unterstützen, führen zur Laufzeit eine Bytecode-Manipulation durch, um statische Methoden zu verspotten.

F # 5) Wie muss überprüft werden, ob der Mock aufgerufen wurde?

Antworten: Das Einrichten eines Stubs für ein verspottetes Objekt (oder eine ausspionierte Instanz) garantiert nicht, ob das Stub-Setup überhaupt aufgerufen wurde.

Mit 'Verifizierungs' -Matchern können Sie überprüfen, ob der eingerichtete Stub tatsächlich aufgerufen wurde oder nicht, wie oft der Aufruf ausgeführt wurde, mit welchen Argumenten die Stubbed-Methode aufgerufen wurde usw.

Im Wesentlichen können wir so den Testaufbau und das erwartete Ergebnis robuster überprüfen.

F # 6) Was ist ein guter testbarer Code?

Antworten:

Einige Punkte zu testbarem Code (was bedeutet, dass er leicht in Einheiten getestet werden kann) sind:

  • Reduziert keine Abhängigkeiten oder enge Kopplung - Beispiel: Abhängigkeiten sollten injiziert und nicht direkt instanziiert werden.
  • Code, der dem SRP (Single Responsibility Principle) entspricht - Dies bedeutet im Wesentlichen, dass die Klasse nicht mehrere Gründe für eine Änderung haben sollte. Durch die Einhaltung von SRP werden Klassen vermieden, die eine Abhängigkeit von sich selbst schaffen, und der Code bleibt zusammenhängend und sauber.
  • Weniger / minimaler Einsatz statischer Methoden und Abschlussklassen - Diese weisen im Allgemeinen auf Codegerüche hin und wurden hauptsächlich mit dem Legacy-Code in Verbindung gebracht.

F # 7) Was sind die Einschränkungen von Mockito?

Antworten: Mockito ist ein Framework der Wahl für die meisten Java-basierten Projekte. Es ist einfach zu implementieren, zu lesen und zu verstehen.

Einige der Nachteile oder Einschränkungen in Bezug auf die Funktionalität sind:

  • Seine Unfähigkeit, statische Methoden zu verspotten.
  • Konstruktoren, private Methoden und Abschlussklassen können nicht verspottet werden.

F # 8) Welche Frameworks können das Verspotten privater und statischer Methoden unterstützen?

Antworten: Frameworks wie PowerMockito (Erweiterungen des Mockito-Frameworks), JMockit usw. bieten Mittel, um private und statische Methoden zu verspotten.

F # 9) Verspotten / Stubben von Standardmethoden in Interface in Java 8.

Antworten: Mit der Implementierung von Standardmethoden in Interface durch Java 8 bietet Mockito sofort Unterstützung, um solche Standardmethoden zu verspotten. (Bitte beachten Sie, dass diese Unterstützung ab Mockito 2 eingeführt wurde.)

Diese Methoden können wie alle anderen Methoden einer Klasse oder Schnittstelle verspottet / gestoppt werden.

F # 10) Wie kann die Reihenfolge der Stub-Aufrufe in Mockito überprüft werden?

Antworten: Wenn Sie die Reihenfolge überprüfen möchten, in der Mocks aufgerufen wurden, wird Mockitos „ In Ordnung ”Schnittstelle kann verwendet werden.

Während des Tests müssen Sie lediglich ein Inorder-Objekt einrichten / erstellen und eine Liste von Mock-Objekten auflisten, für die die Reihenfolge der Mocks ermittelt werden muss (wenn mehrere Methoden für dasselbe Mock vorhanden sind und kein anderes Mock erforderlich ist Um überprüft zu werden, reicht es aus, die verspottete Klasse nur einmal zu erwähnen.

Betrachten Sie den unten angegebenen Test, der ein Objekt von InOrder definiert und zwei Vorkommen von mockDatabaseImpl erwähnt

@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()); }

Als Referenz ist es auch hilfreich, den Code der zu testenden Methode aufzulisten, um die Reihenfolge der Testausführung zu verstehen:

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); }

Wie oben gezeigt, ruft databaseImpl zuerst updateScores und dann getGrade auf.

Wenn Sie also einen Komponententest mit Mockito schreiben und die Reihenfolge der Aufrufe von databaseImpl sicherstellen müssen, lesen Sie den Testcode und stellen Sie sicher, dass die Zusicherungen gemäß der erwarteten Reihenfolge erfolgen.

Wenn ich im obigen Beispiel die Reihenfolge der Asserts ändere, schlägt der Test mit Ausnahme von 'VerificationInOrderFailure' fehl.

Nach dem Ändern der Assert-Reihenfolge sieht der Code wie folgt aus:

@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()); }

Die obige Testausführung löst eine Ausnahme mit dem Typ aus:

etl testet interviewfragen und antworten für erfahrene

'VerificationInOrderFailure' org.mockito.exceptions.verification.VerificationInOrderFailure:
Überprüfung bei Auftragsfehler
Gesucht, aber nicht aufgerufen:
mockDatabaseImpl.updateScores (
isA (java.lang.String),
isA (java.lang.Integer)

F # 11) Rückgabe mehrerer Werte für aufeinanderfolgende Methodenaufrufe

Antworten: Um unterschiedliche Werte für mehrere Aufrufe derselben Stubbed-Methode zurückzugeben, bietet Mockito drei Ansätze:

zu) Mit Komma getrennt: Dies funktioniert mit thenReturn.

Zum Beispiel Lassen Sie uns anhand des obigen Codebeispiels versuchen, einen aufeinanderfolgenden Stub für die Methode getGrade einzurichten, der abhängig von der Reihenfolge der Iterationen unterschiedliche Werte zurückgibt:

when (mockDatabaseImpl.getGrade( anyInt ())).thenReturn('A','B', 'C');

Dies bedeutet, dass beim Aufruf von getGrade-Methoden in der zu testenden Methode der erste Aufruf 'A', der zweite Aufruf 'B' usw. zurückgibt.

b) Aufeinanderfolgende thenReturn: Dies ist ein Ansatz, der mit thenReturn-Anweisungen verkettet ist. Das Anwenden verketteter Anrufe auf dasselbe Beispiel sieht wie unten gezeigt aus.

when (mockDatabaseImpl.getGrade( anyInt ())).thenReturn('A').thenReturn('B').thenReturn('C');

c) Aufeinanderfolgende doReturn: Der letzte Ansatz ist die Verwendung von doReturn im verketteten Format wie oben.

doReturn ('A').doReturn('B').doReturn('C').when(mockDatabaseImpl).getGrade( anyInt ())

F # 12) Was sind die verschiedenen Arten von Spott-Frameworks und wie funktionieren sie?

Antworten: Die Typen des Mocking-Frameworks und ihre Funktionsweise werden nachfolgend erläutert.

Es gibt im Allgemeinen zwei Kategorien von Spott-Frameworks:

  1. Proxy-basiert - - Beispiel, Mockito, EasyMock usw.
  2. Bytecode-basiert - - Beispiel, PowerMock, JMockit usw.

Vergleichen wir diese beiden Frameworks mit verschiedenen Parametern.

Proxy-basiertBytecode-basiert
Einfach ausgedrücktEinfacher und benutzerfreundlicherKönnte eine komplexe Mock-Setup-Logik beinhalten
Art der ErstellungEin Proxy oder ein gefälschtes Objekt, für das keine Instanz der Klasse / Schnittstelle erforderlich ist, wird erstelltEs umfasst im Wesentlichen das Erstellen von Objekten und das Manipulieren der Instanzen zur Laufzeit für das verspottete / gestoppelte Verhalten
FunktionalitätSpottklassen und SchnittstellenErmöglicht neben Klassen und Schnittstellen das Verspotten statischer Methoden, Abschlussklassen usw.
Java-AbhängigkeitNicht sehr eng mit Java-Versionen verbundenDa diese Frameworks eine Bytecode-Manipulation beinhalten, sind sie eng miteinander verbunden und möglicherweise nicht abwärts- / vorwärtskompatibel für Java-Versionen.
BeispieleMockito, EasyMock etc.PowerMock, JMockit usw.

Fazit

Der in diesem Artikel behandelte Inhalt dient grundlegenden Diskussionen über Mocking-Frameworks und speziell die Vorbereitung von Mockito-Interviews.

Neben einem theoretischen Verständnis der behandelten Fragen sollte man auch versuchen, echte Codebeispiele zu erstellen, die das Erlernen dieser Frameworks unterhaltsamer und interessanter machen.

Ich hoffe, Ihnen hat die gesamte Palette der Tutorials in dieser Mockito-Serie gefallen.

Viel Spaß beim Lernen.

PREV Tutorial | ERSTES Tutorial

Literatur-Empfehlungen

^