Menü

Mockito Tutorial: Mockito Framework zum Verspotten im Unit Testing

  • Haupt
  • Andere
  • Mockito Tutorial: Mockito Framework zum Verspotten im Unit Testing

mockito tutorial mockito framework

Versuchen Sie Unser Instrument, Um Probleme Zu Beseitigen

Eine vollständige Anleitung zum Mockito Framework: Praktische Mockito-Tutorials

Testfall Vorlage Excel kostenloser Download

Unit-Tests sind eine einfache und dennoch effektive Technik, um ein gutes Maß an Vertrauen in den zu versendenden Code zu gewinnen.

Darüber hinaus werden Regressionsprobleme bei jedem eingecheckten Code vermieden.

Bei einer Architektur mit Mikrodiensten (und selbst bei einer einfachen Struktur mit grundlegenden Datenbankaufrufen) reichen einfache Unit-Tests nicht aus. Was wir brauchen, ist, die Abhängigkeiten zu verspotten und die tatsächliche Logik der zu testenden Methode zu testen.

Mockito Tutorial-Anleitung

Liste ALLER Mockito-Tutorials in dieser Reihe:

Tutorial Nr. 1: Mockito Framework zum Verspotten im Unit Testing (Dieses Tutorial)
Tutorial # 2: Mocks und Spione in Mockito erstellen
Tutorial # 3: Verschiedene Arten von Matchern von Mockito
Tutorial # 4: Verspotten privater, statischer und nichtiger Methoden mit Mockito
Tutorial Nr. 5: Top 12 Mockito Interview Fragen

********************************************************** ********************

Übersicht der Tutorials in dieser Mockito-Serie

Lernprogramm #Was du lernen wirst
Tutorial Nr. 1: Mockito Framework zum Verspotten im Unit Testing

Lernen Sie das Verspotten mit Mockito - Ein umfassendes Mockito-Tutorial für Anfänger mit Codebeispielen. Lernen Sie das Mocking Framework zum Verspotten in Unit Testing.
Tutorial # 2: Mocks und Spione in Mockito erstellen

Mocks and Spies sind Arten von Test-Doubles, die beim Schreiben von Unit-Tests hilfreich sind. Beide werden in diesem Mockito Spy-Tutorial mit Codebeispielen erläutert.
Tutorial # 3: Verschiedene Arten von Matchern von Mockito

Erfahren Sie, wie Sie verschiedene Arten von Matchern verwenden, die von Mockito bereitgestellt werden. Matcher sind wie Platzhalter, bei denen Sie anstelle einer bestimmten Eingabe / Ausgabe einen Eingabebereich angeben. Argument und Verifikation sind die beiden Arten von Matchern in Mockito, die hier ausführlich erläutert werden.
Tutorial # 4: Verspotten privater, statischer und nichtiger Methoden mit Mockito

Lernen Sie in Mockito anhand von Beispielen, wie Sie private, statische und leere Methoden verspotten. Erfahren Sie, wie Sie private und statische Methoden mit dem Unit-Test-Framework PowerMockito verspotten.
Tutorial Nr. 5: Top 12 Mockito Interview Fragen

Mockito Interview Fragen und Antworten mit Beispielcodebeispielen. Dies wird Ihnen helfen, jedes Mockito Mocking Framework-Interview erfolgreich zu knacken.

Beginnen wir mit dem ersten Tutorial in dieser Reihe!

Was du lernen wirst:

Verspottung beim Unit-Test

Mocks / Stubs ist ein Begriff, den Menschen häufig hören, wenn sie insbesondere Unit-Tests erstellen.

Also, was ist eigentlich Spott? In einfachen Worten, es ist nichts anderes als die Bereitstellung einer kontrollierten Instanz oder Implementierung einer Abhängigkeit, von der der zu testende Code abhängt, um seine Kernlogik zu testen.

Der Grund, warum ich es als kontrollierte Instanz erwähnt habe, ist, dass das Verhalten der Abhängigkeit für die zu testende Methode oder das zu testende System wie gewünscht programmiert oder gesteuert werden kann.

Um es schematisch zu erklären, nehmen wir ein Beispiel für eine Geschäfts- oder E-Commerce-Anwendung. Fast jede solche Art von Anwendung hat hauptsächlich 3 Schichten, d.h. Benutzeroberfläche, Geschäftsschicht und Datenzugriffsschicht (der mit dem zugrunde liegenden Datenspeicher spricht)

Beispiel: UnitTesting-Abhängigkeiten

Unter Bezugnahme auf das obige Diagramm weist die Geschäftsschicht drei Abhängigkeiten auf, nämlich eine Datenzugriffsschicht und zwei andere Dienste, die Dienst 1 und Dienst 2 sind.

Betrachten Sie es so - Eine App wie Google Maps kann Abhängigkeiten von einem haben

  1. Tatsächliche Datenspeicher wie MySQL oder jede andere No-SQL-Datenbank, in der Kartendaten gespeichert sind.
  2. Ein externer Dienst wie CoordinateService, der Breiten- und Längengrade eines Standorts bereitstellt.
  3. Ein externer Dienst wie der Verkehrsdienst, der Verkehrsinformationen in Echtzeit für ein bestimmtes Koordinatenpaar bereitstellt.

Wenn also jemand versucht, die Kerngeschäftslogik mithilfe eines Komponententests zu validieren, können die Tests nicht ausgeführt werden, bis diese Abhängigkeiten funktionieren.

In diesen Situationen, in denen Ihre Abhängigkeit unabhängig davon, ob Ihre Abhängigkeit besteht oder nicht, Ihre Geschäftslogik immer mit einer programmierten Antwort auf die Abhängigkeit ausgeführt wird, die vom zu testenden Code aufgerufen wird, können Sie Mocks retten.

Arten / Kategorien von Testdoppel

Mock ist im Wesentlichen eine Art 'Test Double' - es ist eine Fachsprache. 'Test Double' bedeutet im Wesentlichen ein Objekt, das durch eine äquivalente reale Objektinstanz oder -abhängigkeit ersetzt wird.

Es gibt verschiedene Arten von Testdoppeln, wie unten erwähnt:

# 1) Fälschungen:

Eine Fälschung ist eine funktionierende Implementierung, die einer realen Abhängigkeit ähnelt, mit der Ausnahme, dass sie lokal für das zu testende System ist.

Beispiel: Anstatt eine echte Produktionsdatenbank zu treffen, verwendet der Test eine einfache Sammlung / In-Memory zum Speichern von Daten.

Art der Testdoppel - Fälschungen

# 2) Stubs:

Stubs sind vorkonfigurierte Antworten, wenn eine Abhängigkeit vom zu testenden System aufgerufen wird.

Art der Testdoppelstummel

# 3) Spione:

Wie der Name schon sagt, handelt es sich tatsächlich um den eigentlichen Funktionsaufruf (Abhängigkeitsaufruf) mit einem Überwachungsmechanismus. Nach dem Anruf kann überprüft werden, ob der Anruf tatsächlich ausgelöst wurde oder nicht, zusammen mit den Parametern.

Art der Testdoppelspione

# 4) Verspottung:

Mocks sind spezielle Instanzen von Objekten, für die Stubbed / vorkonfigurierte Antworten angegeben werden können. Die Tatsache, dass der Mock aufgerufen wurde, kann im Test als Behauptung verifiziert werden.

Zum Beispiel:

Es gibt eine Berichtsgeneratorfunktion, die während der Ausführung eine E-Mail an eine bestimmte Adresse sendet.

Da wir während des Tests nicht immer wieder aktuelle E-Mails senden möchten, wird der EmailService verspottet (und die E-Mail-Methode, mit der die E-Mail gesendet wird, ist so konfiguriert, dass beim Aufrufen nichts unternommen wird). Am Ende des Tests können wir nur überprüfen, ob die E-Mail-Versandmethode des E-Mail-Dienstes über das verspottete Objekt aufgerufen wurde.

Verschiedene Mocking Frameworks

Fast alle Sprachen bieten unterschiedliche Arten von Spott-Frameworks. Wir werden einen Beispielcode mit Mockito schreiben, einem Open-Source-Mocking-Framework für Java.

Anatomie eines einfachen Unit-Tests mit verspotteter Abhängigkeit. Angenommen, wir versuchen, eine Anwendung zu testen, die die Gesamtpunktzahl für einen Schüler in allen Fächern berechnet und in die DB schreibt.

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

Wenn wir nun einen Komponententest für die Methode 'berechneSumAndStore' schreiben möchten, haben wir möglicherweise keine echte Implementierung einer Datenbank zum Speichern der Gesamtsumme. In diesem Fall können wir diese Funktion nie testen.

Mit vorhandenen Mocks können wir jedoch einfach einen Mock für den Datenbankdienst übergeben und den Rest der Logik validieren

Beispieltest wie unten gezeigt:

@Test public void calculateSumAndStore_withValidInput_shouldCalculateAndUpdateResultInDb() { // Arrange studentScores = new StudentScoreUpdates(mockDatabase); int() scores = { 60, 70, 90 }; Mockito.doNothing().when(mockDatabase).updateScores('student1', 220); // Act studentScores.calculateSumAndStore('student1', scores); // Assert Mockito.verify(mockDatabase, Mockito.times(1)).updateScores('student1', 220); }

Wir haben im obigen Test gesehen, dass wir der übergeordneten Klasse ein mockDatabase-Objekt bereitgestellt haben (für die zu testende Methode) und eine Stub-Antwort für das mockedDatabase-Objekt eingerichtet haben - Zeile 6 oben (Mockito.doNothing (). When (mockDatabase) .updateScores ('student1', 220);)

Die wichtigsten Punkte, die aus dem oben Gesagten zu beachten sind, sind:

# 1) Das verspottete Objekt muss Stub-Antworten für alle Methoden einrichten, die während der Funktionsausführung aufgerufen werden.

#zwei) Die während der Stub-Erstellung angegebenen Parameter können spezifisch oder generisch sein.

Beispiel Im obigen Fall haben wir die Parameter für die updateScores-Methode als 'student1' und 220 angegeben, da wir wissen, dass dies die genauen Eingaben sind, mit denen unsere Methode aufgerufen werden soll.

# 3) Während der Überprüfung validieren wir Folgendes:

  • Die Methode mockDatabase.updateScores wurde aufgerufen.
  • Die Argumente waren 'student1' bzw. 220.
  • Die updateScores-Methode wurde einmal aufgerufen.

Versuchen wir nun, diesen Testcode ein wenig zu ändern und zu sehen, was passiert:

Ich werde das Argument im Mock-Setup von 'student1' in anyString ändern (Mockito bietet einen Standard-Matcher mit dem Namen anyString ()) und 220 in anyInteger (Mockito stellt einen Standard-Matcher mit dem Namen anyInt () bereit und stimmt mit einem beliebigen Integer-Wert überein).

@Test public void calculateSumAndStore_withValidInput_shouldCalculateAndUpdateResultInDb() { // Arrange studentScores = new StudentScoreUpdates(mockDatabase); int() scores = { 60, 70, 90 }; Mockito.doNothing().when(mockDatabase).updateScores(anyString(), anyInt()); // Act studentScores.calculateSumAndStore('student1', scores); // Assert Mockito.verify(mockDatabase, Mockito.times(1)).updateScores('student1', 220); }

Versuchen Sie erneut, den Test auszuführen, und der Test sollte immer noch grün sein.

(Versuchen wir nun, die Überprüfung / Asserts zu ändern und eines der Argumente zu ändern.

Ändern wir 220 in 230. Nun wird erwartet, dass der Test fehlschlägt, da dies nicht das erwartete Argument ist, mit dem das databaseUpdate aufgerufen worden sein muss.

@Test public void calculateSumAndStore_withValidInput_shouldCalculateAndUpdateResultInDb() { // Arrange studentScores = new StudentScoreUpdates(mockDatabase); int() scores = { 60, 70, 90 }; Mockito.doNothing().when(mockDatabase).updateScores(anyString(), anyInt()); // Act studentScores.calculateSumAndStore('student1', scores); // Assert Mockito.verify(mockDatabase, Mockito.times(1)).updateScores('student1', 230); }

Lesen Sie nach dem Ausführen des Tests die unten gezeigten Fehlerprotokolle (es wird deutlich erwähnt, dass die tatsächlichen Argumente nicht mit den erwarteten übereinstimmten).

Argumente sind unterschiedlich! Gesucht:
mockDatabase.updateScores ('student1', 230);
-> at com.mocking.sampleMocks.StudentScoreUpdatesUnitTests.calculateSumAndStore_withValidInput_shouldCalculateAndUpdateResultInDb (StudentScoreUpdatesUnitTests.java:37)

Der tatsächliche Aufruf hat verschiedene Argumente:
mockDatabase.updateScores ('student1', 220);

Quellcode

Schnittstelle - IDatabase.java

public interface IDatabase { public void updateScores(String studentId, int total); }

Zu testende Klasse - StudentScoreUpdates.java

public class StudentScoreUpdates { public IDatabase databaseImpl; public StudentScoreUpdates(IDatabase databaseImpl) { this.databaseImpl = databaseImpl; } 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); } }

Unit Tests Class - StudentScoreUpdatesUnitTests.java

public class StudentScoreUpdatesUnitTests { @Mock public IDatabase mockDatabase; public StudentScoreUpdates studentScores; @BeforeEach public void beforeEach() { MockitoAnnotations.initMocks(this); } @Test public void calculateSumAndStore_withValidInput_shouldCalculateAndUpdateResultInDb() { // Arrange studentScores = new StudentScoreUpdates(mockDatabase); int() scores = {60,70,90}; Mockito.doNothing().when(mockDatabase).updateScores(anyString(), anyInt()); // Act studentScores.calculateSumAndStore('student1', scores); // Assert Mockito.verify(mockDatabase, Mockito.times(1)).updateScores('student1', 230); } }

Fazit

Was wir bisher gesehen haben, ist ein sehr einfaches und unkompliziertes Beispiel für das Mock-Setup mit dem Mockito-Framework von Java.

Für fast 60-70% der Unit-Tests mit Mocks sollten die Tests eine ähnliche Struktur haben. Mockito bietet eine Menge erweiterter Konfiguration / Unterstützung für umfangreiche Verspottungsbedürfnisse, das Einfügen von Scheininstanzen mithilfe der Abhängigkeitsinjektion, bietet Spies die Möglichkeit, einen echten Methodenaufruf auszuspionieren und die Aufrufe zu überprüfen.

In unserem nächsten Tutorial erfahren Sie mehr über das Konzept der Spötter und Spione in Mockito.

NÄCHSTES Tutorial

Literatur-Empfehlungen

^