Menü

Wiremock Tutorial: Einführung in Wiremock

  • Haupt
  • Andere
  • Wiremock Tutorial: Einführung in Wiremock

wiremock tutorial introduction wiremock

Versuchen Sie Unser Instrument, Um Probleme Zu Beseitigen

In diesem einführenden Video-Tutorial werden die Funktionen von Wiremock und die Ausführung von Wiremock als eigenständiger Server und als Teil von JUnit-Tests erläutert:

In diesem Tutorial werden die grundlegenden Konzepte und Details rund um das Wiremock-Tool behandelt. Es kann als eigenständiger HTTP-Server sowie innerhalb der JUnit-Tests gemäß den Anforderungen verwendet werden.

Dies ist ein häufig verwendetes Tool, da es Open Source ist und eine große Community von Mitwirkenden hat. Es fällt unter die Kategorie der Service-Virtualisierungstools.

Wiremock Tool Einführung

Was du lernen wirst:

Was ist Wiremock?

In einfachen Worten, Wiremock ist ein spöttisches Setup für Integrationstests. Es handelt sich lediglich um einen Mock-Server, der in hohem Maße konfigurierbar ist, um eine erwartete Antwort für eine bestimmte Anforderung zurückzugeben.

Es wird häufig während der Entwicklung und vor allem beim Integrationstest verwendet, während ein System oder Dienst mit einer oder mehreren externen oder internen Abhängigkeiten / Diensten kommuniziert.

Versuchen wir, mehr über Integrationstests im Allgemeinen zu erfahren und zu erfahren, wie Wiremock dazu beitragen kann, diese Herausforderungen zu bewältigen und unser Leben zu erleichtern.

Wenn das Wort Integration kommt, fällt uns im Allgemeinen eine End-to-End-Integration zwischen zwei Kommunikationssystemen auf. Betrachten wir es nun aus der Perspektive einer zu testenden Anwendung, die einen externen Dienst verwendet, um die Aufgabe zu erledigen.

Zum Beispiel, Nehmen wir an, wir erstellen eine Anwendung für ein Online-Reise- oder Ticketingsystem und haben ein Modul für die PNR-Statusprüfung, das auf eine externe API der Indian Railways trifft.

Wie können wir nun unsere Anwendung mit den externen APIs integrieren?

Es gibt zwei Möglichkeiten, dies zu tun:

  • Zuerst, ist der Unit-Test-Ansatz, bei dem wir die bereitgestellte (oder intern erstellte) Schnittstelle stubben, damit unser System die stubbelte oder gefälschte Antwort testet / validiert, noch bevor die externe API aufgerufen wird. Dies ist nichts anderes als ein Unit-Test, der versucht, eine externe Abhängigkeit zu verspotten.
  • Zweite testet die externen Abhängigkeiten mit einer Testumgebung (oder der tatsächlichen Produktionsumgebung). Bei diesem Ansatz gibt es jedoch mehrere Herausforderungen:
    • Externe API-Systeme sind möglicherweise nicht immer verfügbar. d.h. wir sind stark abhängig oder abhängig von externen Systemen, und Ausfallzeiten wirken sich auf unsere Tests und indirekt auf den Entwicklungs- / Freigabeprozess aus.
    • Zweitens können externe APIs eine Testumgebung haben oder nicht. Zum Beispiel, Für eine PNR-Statusprüfungs-API sind möglicherweise immer echte PNR-Nummern erforderlich, um Antworten abzurufen und zurückzugeben.
    • Oft sind mit dem Erreichen einer API Kosten verbunden. Zum Beispiel, Angenommen, die PNR-Überprüfungs-API berechnet Rs 100 für jeweils 1000 Anforderungen. Da Integrationstests normalerweise während jeder Regression (und meistens bei jedem Commit) ausgeführt werden, ist es möglicherweise keine kostengünstige Lösung, eine solche API zu verwenden, die uns selbst für Testzwecke kostet.
    • Eine externe API kann nicht so konfiguriert werden, dass sie die gewünschte Antwort zurückgibt. Selbst wenn möglich, müssen Sie viele Testdaten erstellen, um unterschiedliche Antworten für unterschiedliche Anforderungseingaben sicherzustellen.
      Zum Beispiel, Sie möchten Fehlerszenarien testen, z. B. wenn eine API unterschiedliche Statuscodes für unterschiedliche Datentypen zurückgibt. Da die Antwort nicht unter unserer Kontrolle steht, müssen wir mehrere Datensätze erstellen, um verschiedene mögliche Szenarien oder Ergebnisse zu validieren.

Lassen Sie uns diese Konzepte anhand des folgenden Diagramms verstehen.

Hier vergleichen wir beide Ansätze des Integrationstests, d. H. Ohne einen Mock-Server, unter Verwendung einer tatsächlichen Implementierung der externen Abhängigkeit und unter Verwendung des Mock-Servers (Wiremock), der die Antworten auf die für die Abhängigkeit empfangenen Anforderungen verspottet.

Im letzteren Fall wird die Abhängigkeit und Abhängigkeit von der tatsächlichen Implementierung der Abhängigkeit erheblich reduziert und es werden viele Konfigurationsfunktionen bereitgestellt, ohne dass die Qualität und die Lieferpläne beeinträchtigt werden.

Wiremock-Konzepte

Wie reagiert Wiremock auf eine bestimmte Anfrage?

Wie wir wissen, ist Wiremock ein programmatischer Mock-Server. Die Antwort auf eine bestimmte Anfrage besteht darin, alle relevanten Zuordnungen (oder verspotteten Antworten) in einem Ordner mit dem Namen 'Zuordnungen' zu speichern.

Es gibt eine Matcher-Komponente von Wiremock, die eingehende Anforderungen mit den gespeicherten Zuordnungen vergleicht. Wenn eine erfolgreiche Übereinstimmung zurückgegeben wird, wird die erste solche Übereinstimmung als Antwort auf die angegebene Anforderung zurückgegeben.

Wenn Sie die eigenständige Version von Wiremock verwenden, wird nach dem Ausführen des Wiremock-Servers der Zuordnungsordner angezeigt, der im Verzeichnis 'Wiremock install / jar location' erstellt wird.

Video-Tutorial: Einführung in das Wiremock Tool

Wofür wird C ++ heute verwendet?

Wie benutzt man Wiremock?

Nun wollen wir sehen, wie wir dieses Tool mit unseren Integrationstests verwenden können.

Es kann auf folgende Arten verwendet werden.

Ein eigenständiger Wiremock-Server

Als eigenständiger Server können Sie einfach eine einfache Java-Anwendung mit Maven / Gradle-Abhängigkeit für Wiremock erstellen und als laufenden Prozess beibehalten.

Dies ist eine gute Alternative, wenn Sie Ihren eigenständigen Server auf einem Computer hosten und als einzelnen Verspottungsserver für das gesamte Projekt oder Team verwenden möchten. Im Standalone-Modus kann dieses Tool auch ausgeführt werden, indem das verfügbare Standalone-JAR heruntergeladen wird Hier und einfach das Glas laufen lassen.

Zum Beispiel, Angenommen, Sie möchten Ihre eigenständige Wiremock-Instanz auf einem Server in der Cloud oder auf einem lokalen Server bereitstellen. Dann können Sie diese JAR-Datei einfach ausführen und die System-IP verwenden, um sie als gehosteten Dienst zu verwenden.

Mal sehen Schritte, um dies im Standalone-Modus auszuführen (und verschiedene Dinge wie Ports, Zuordnungsordner usw. zu konfigurieren)

# 1) Führen Sie das Wiremock-JAR über das Terminal (oder die Eingabeaufforderung für Windows-Benutzer) wie jede andere JAR-Datei (aus dem Installationsverzeichnis des Wiremock-JAR) aus.

java -jar wiremock-standalone-2.25.1.jar

#zwei) Standardmäßig wird Wiremock auf localhost: 8080 ausgeführt (wenn der Port frei ist, startet der obige Befehl den Wiremock-Server in einem eigenständigen Modus), und die Ausgabe wird wie folgt angezeigt.

Wiremock läuft auf localhost

#3) Sobald der Server gestartet ist, können Sie eine beliebige URL auf localhost aufrufen: 8080

Zum Beispiel, http: // localhost: 8080 / get / user / 1 - Da derzeit keine Mocks festgelegt sind, erhalten Sie eine Antwort wie unten gezeigt.

Wiremock-Antwort

# 4) Versuchen wir nun, einen einfachen Stub / Mock für diese URL einzurichten und die URL erneut zu drücken. Wir werden dann überprüfen, ob das Treffen derselben URL jetzt die verspottete oder gestoppelte Antwort zurückgibt.

curl -X POST --data '{ 'request': { 'url': '/get/user/1', 'method': 'GET' }, 'response': { 'status': 200, 'body': 'Here it is! ' }}' http://localhost:8080/__admin/mappings/new

Versuchen wir zunächst, diese CURL-Anforderung zu verstehen:

  • Wir senden eine CURL POST-Anfrage an http: // localhost: 8080 / __ admin / mappings / new - Dies ist nun der Speicherort, an dem alle Zuordnungen für den Wiremock-Server gespeichert werden, den wir über die JAR-Datei ausgeführt / gestartet haben.
  • In der Curl-Anforderung definieren wir Anforderungsparameter wie - URL und Anforderungsmethode zusammen mit dem Antworttext im Abschnitt 'Antwort'. Dies impliziert einfach, dass jedes Mal, wenn eine GET-Anfrage mit der URL / get / user / 1 eingeht, mit dem angegebenen Antworttext geantwortet wird.

# 5) Sobald die gestoppte Antwort festgelegt ist (mithilfe der obigen Curl-Anforderung), können wir versuchen, die URL zu treffen und festzustellen, ob wir eine gestubbte Antwort vom Wiremock zurückerhalten.

Versuchen wir, diese URL im Browser aufzurufen: http: // localhost: 8080 / get / user / 1

Wenn die Zuordnung erfolgreich festgelegt wurde, sollten Sie eine Antwort erhalten, wie unten gezeigt:

Zuordnung wurde erfolgreich festgelegt

Zusammen mit JUnit-Tests als JUnit-Regelkonfiguration

Der Wiremock-Server kann mit JUnit-Tests als JUnit-Regel-Setup verwendet werden. Damit kümmert sich JUnit um den Wiremock-Lebenszyklus, d. H. Wiremock startet und stoppt.

ist c ++ besser als Java

Es wird hauptsächlich in Setups verwendet, in denen Sie den Server nach jedem Test starten und stoppen möchten.

Dies hat seine eigenen Vorteile, isoliert zu sein, und ein hohes Maß an Konfigurierbarkeit im Gegensatz zu einem eigenständigen Setup, bei dem mehrere Personen denselben Server verwenden und sich gegenseitig über die gestoppelten Antworten hinwegsetzen können.

Sehen wir uns ein funktionierendes Beispiel für diesen Ansatz an:

# 1) Erstellen Sie eine JUnit-Regel für den Wiremock-Server. Dieser Schritt ähnelt im Wesentlichen einem Test-Setup-Schritt, bei dem der JUnit-Runner angewiesen wird, den Wiremock-Server vor jedem Test zu instanziieren und den Server nach jedem Test anzuhalten.

Dies bedeutet auch, dass JUnit Runner das Starten und Stoppen des Wiremock-Servers übernimmt, ohne dies explizit zu tun.

@Rule public WireMockRule wm = new WireMockRule(wireMockConfig().port(8080));

#zwei) Jetzt schreiben wir unseren Test, in dem wir zuerst unseren Client (mit okHttp) erstellen, um Anforderungen für den gewünschten Endpunkt auszuführen.

// execute request through http client OkHttpClient client = new OkHttpClient(); Request request = new Request.Builder() .url('http://localhost:8080/test/abc') .get() .build();

#3) Sie können hier jedoch feststellen, dass wir noch keinen Stub für unsere Wiremock-Instanz festgelegt haben. d.h. der obige Client fordert eine URL http: // localhost: 8080 / test / abc an, für die kein Stub konfiguriert ist. In diesem Fall gibt der Wiremock-Server einen 404 no content zurück.

# 4) Um nun einen Stub für die obige URL für unsere Wiremock-Serverinstanz festzulegen, müssen wir die statischen Stub-Methoden des Wiremock wie unten gezeigt aufrufen.

private void configureStubs() { configureFor('localhost', 8080); stubFor(get(urlEqualTo('/test/abc')) .willReturn(aResponse().withBody('Test success!'))); }

Hier sehen Sie, dass wir einige statische Methoden wie configureFor, stubFor usw. verwendet haben. Alle diese Methoden sind Teil der Wiremock Java-Bibliothek. (Wir werden uns diese Methoden in unserem nächsten Tutorial / Abschnitt genauer ansehen.)

# 5) Nachdem der Konfigurationsschritt abgeschlossen ist, können wir die Anforderung einfach über den Client ausführen und die Antwort validieren (abhängig davon, was konfiguriert ist, damit der Stub über Wiremock zurückkehrt).

Zusammenfassend sieht das gesamte Codebeispiel folgendermaßen aus:

public class WiremockJunitTest { @Rule public WireMockRule wm = new WireMockRule(wireMockConfig().port(8080)); @Test public void assertWiremockSetup() throws IOException { // Arrange - setup wiremock stubs configureStubs(); // execute request through the http client OkHttpClient client = new OkHttpClient(); Request request = new Request.Builder() .url('http://localhost:8080/test/abc') .get() .build(); // Act - call the endpoint Response response = client.newCall(request).execute(); // Assert - verify the response assertEquals('Test success!', response.body().string()); verify(exactly(1),getRequestedFor(urlEqualTo('/test/abc'))); } // configure stubs for wiremock private void configureStubs() { configureFor('localhost', 8080); stubFor(get(urlEqualTo('/test/abc')) .willReturn(aResponse().withBody('Test success!'))); } }

Abhängigkeiten erforderlich

Es ist erhältlich als:

  • Eine eigenständige JAR, die nur die Wiremock-Abhängigkeit enthält.
  • Ein fettes Glas mit Wiremock und all seinen Abhängigkeiten.

Beide Geschmacksrichtungen sind als Gradle- und Maven-Abhängigkeiten verfügbar. Weitere Informationen finden Sie im offiziellen Maven-Repository Hier

Video-Tutorial: Wiremock mit JUnit-Test

Fazit

In diesem Tutorial haben wir die Grundfunktionen von Wiremock kennengelernt und gesehen, wie es als eigenständiger Server und als Teil der JUnit-Tests mit JUnit-Regeln ausgeführt werden kann.

Wir haben auch kurz auf Stubbing eingegangen und werden dies in unserem nächsten Tutorial ausführlich behandeln.

NÄCHSTES Tutorial

Literatur-Empfehlungen

^