18. Mär 2024
Lesedauer 16 Min.
Effizientes Mocking für .NET
WireMock.NET: APIs simulieren
Das Mocking von APIs ist ein wichtiger Aspekt beim Testen. Die Bibliothek WireMock.NET bietet dazu zahlreiche Funktionen an und verspricht einen schnellen Einstieg.
dotnetpro
Die Fähigkeit, externe Abhängigkeiten effizient zu simulieren, ist in Softwareprojekten von entscheidender Bedeutung. Dies gilt insbesondere für Anwendungen, die auf externe Dienste und APIs angewiesen sind. Hier kommt WireMock.NET ins Spiel, eine leistungsstarke .NET-Bibliothek, die es ermöglicht, HTTP-basierte Services zu mocken und zu simulieren. Durch den Einsatz von WireMock.NET lassen sich realistische Testumgebungen erstellen, die das Verhalten externer Abhängigkeiten nachahmen, ohne dass diese tatsächlich verfügbar sein müssen. Dies erleichtert das Testen von Anwendungen unter verschiedenen Bedingungen und hilft dabei, potenzielle Probleme frühzeitig zu identifizieren.Die Bedeutung von WireMock.NET erstreckt sich über einfache Mocking-Funktionen hinaus. Mit erweiterten Features wie Response Templating, Stateful Behavior und der Möglichkeit, echte API-Antworten aufzuzeichnen und wiederzugeben, bietet WireMock.NET eine flexible Plattform, die komplexe Testszenarien unterstützt.Diese Episode von Frameworks und mehr behandelt daher WireMock.NET im Detail. Im Fokus stehen die Grundlagen der Bibliothek, praktische Anwendungen und erweiterte Funktionen, um zu zeigen, wie diese Bibliothek die Qualitätssicherung in der Softwareentwicklung verbessern kann.
.NET-Projekte und seiner umfassenden Funktionalität schnell zu einem der führenden Tools in der .NET-Community entwickelt. Die Entwicklung von WireMock.NET ist von der Notwendigkeit angetrieben, eine robuste und flexible Lösung für das Mocking von HTTP-Services in der .NET-Umgebung zu bieten. Die Mitwirkenden rund um das Projekt sorgen für eine kontinuierliche Weiterentwicklung, um neue Features zu integrieren und sich an die sich ändernden Anforderungen der modernen Softwareentwicklung anzupassen.
Herausforderungen
Mocking ist in verschiedenen Bereichen der Softwareentwicklung von Bedeutung. In der Unit-Test-Phase ermöglicht es das Isolieren von Komponenten, um ihre Funktionalität unabhängig von externen Systemen zu überprüfen. Bei Integrationstests hilft Mocking, die Interaktion zwischen verschiedenen Modulen zu testen, ohne auf externe Abhängigkeiten angewiesen zu sein. In der End-to-End-Testphase lassen sich durch Mocking komplexe Anwendungsszenarien in einer kontrollierten Umgebung nachstellen, was bei der Identifizierung und Behebung von Fehlern hilft.Eine der größten Herausforderungen beim Mocking liegt in der korrekten Simulation von externen Abhängigkeiten. Es ist entscheidend, dass die Mocks das Verhalten dieser Services realistisch nachbilden, um aussagekräftige Testergebnisse zu erhalten. Dies erfordert ein tiefes Verständnis der externen Systeme sowie der Anforderungen der Anwendung, die getestet werden soll.Ein weiteres Problem ist die Aufrechterhaltung der Aktualität und Relevanz der Mocks. Externe Services entwickeln sich weiter, und Mocks sind entsprechend anzupassen, um mit diesen Änderungen Schritt zu halten. Dies kann insbesondere in agilen Entwicklungsprozessen, bei denen schnelle Iterationen und Anpassungen die Norm sind, eine Herausforderung darstellen.Mocking ist ein wesentlicher Bestandteil der Softwareentwicklung, da es die Erstellung robuster, zuverlässiger und unabhängig testbarer Anwendungen ermöglicht. Die Herausforderungen, die es mit sich bringt, sind ein kleiner Preis für die Vorteile, die es bietet.Überblick und Grundlagen von WireMock.NET
Wie in der Einleitung kurz erwähnt, ist WireMock.NET eine flexible .NET-Bibliothek für das Mocking von HTTP-basierten Diensten. Die Bibliothek ermöglicht es, das Verhalten von Webdiensten in Tests zu simulieren, was für die Entwicklung und das Testen von Anwendungen, die auf externe HTTP-Schnittstellen angewiesen sind, unerlässlich ist. Diese Bibliothek ist besonders nützlich, um konsistente, wiederholbare und isolierte Testumgebungen für Unit- und Integrationstests zu schaffen.Der Hauptzweck von WireMock.NET ist es daher, einen HTTP-Server-Mock anzubieten, der Anfragen auf der Basis voreingestellter Regeln empfängt und darauf reagiert. Es lässt sich genau definieren, wie auf eine spezifische HTTP-Anfrage, basierend auf URL, Methode, Headern oder Body-Inhalt, geantwortet werden soll. Dies ermöglicht ein hohes Maß an Flexibilität und Kontrolle über die Testumgebung.WireMock.NET [1] ist inspiriert von WireMock [2], einem populären Java-basierten Mocking-Tool, und wurde speziell für die .NET-Plattform entwickelt. Seit seiner Einführung hat es sich dank seiner einfachen Integration in bestehende.NET-Projekte und seiner umfassenden Funktionalität schnell zu einem der führenden Tools in der .NET-Community entwickelt. Die Entwicklung von WireMock.NET ist von der Notwendigkeit angetrieben, eine robuste und flexible Lösung für das Mocking von HTTP-Services in der .NET-Umgebung zu bieten. Die Mitwirkenden rund um das Projekt sorgen für eine kontinuierliche Weiterentwicklung, um neue Features zu integrieren und sich an die sich ändernden Anforderungen der modernen Softwareentwicklung anzupassen.
Architektur auf Basis von Kernkomponenten
Die Architektur von WireMock.NET basiert auf einigen Kernkomponenten und ist speziell darauf ausgelegt, ein hohes Maß an Flexibilität und Kontrolle über das Verhalten von Mock-Services zu bieten. Dies ermöglicht eine effiziente Nachbildung externer APIs und Dienste für Testzwecke.- Server-Instanzierung: Im Herzen von WireMock.NET steht die Server-Instanz, die als zentraler Punkt für das Empfangen und Verarbeiten eingehender HTTP-Anfragen dient. Diese Instanz kann leicht konfiguriert und gestartet werden, wobei Entwickler spezifische Port-Nummern und andere Einstellungen wie SSL-Zertifikate und Proxy-Einstellungen festlegen können.
- Request Matching: Ein Kernelement von WireMock.NET ist das ausgeklügelte Request-Matching-System. Es erlaubt Entwicklern, spezifische Regeln für das Erkennen eingehender Anfragen zu definieren, basierend auf URL-Pfaden, HTTP-Methoden, Headern, Query-Parametern und Body-Inhalten. Durch den Einsatz regulärer Ausdrücke oder benutzerdefinierter Matching-Implementierungen lassen sich komplexe Matching-Kriterien erstellen, um ein realistisches Mocking-Verhalten zu erreichen.
- Response Definition: Nach dem erfolgreichen Matching einer Anfrage ermöglicht WireMock.NET die Definition einer maßgeschneiderten Antwort. Entwickler können den HTTP-Statuscode, Header und Body der Antwort festlegen. Dank der Unterstützung für dynamische Antworten mittels Response Templating lassen sich Mock-Antworten basierend auf den Details der eingehenden Anfrage generieren, was eine noch genauere Simulation ermöglicht.
- Erweiterte Funktionen: WireMock.NET bietet eine Vielzahl erweiterter Funktionen, die über einfaches Request Matching und Response Definition hinausgehen. Dazu gehören die Simulation von Netzwerkverzögerungen, das Erzeugen zufälliger Fehler, Stateful Behavior für das Simulieren von Anwendungen mit Zuständen und das Aufzeichnen und Wiedergeben von Anfragen für das Testen mit realen Daten. WireMock.NET bietet zudem die Möglichkeit, reale HTTP-Anfragen und -Antworten aufzuzeichnen und später als Mocks zu verwenden. Dies ist besonders nützlich, um realistische Testumgebungen zu schaffen.
- Flexibilität und Erweiterbarkeit: Die Architektur von WireMock.NET ist so gestaltet, dass sie leicht erweitert und an spezifische Bedürfnisse angepasst werden kann. Entwickler können eigene Request Matcher und Response Transformer implementieren, um benutzerdefinierte Logik in den Mocking-Prozess einzubringen.
Installation und erste Server-Konfiguration
Die Installation von WireMock.NET in einem .NET-Projekt ist unkompliziert. Zunächst ist das WireMock.NET-Paket zu installieren – beispielsweise über den NuGet-Paketmanager, indem das folgende Kommando in der Entwicklungsumgebung oder über die Kommandozeile ausgeführt wird:
Install-<span class="hljs-keyword">Package</span> <span class="hljs-title">WireMock.Net</span>
Nach der Installation ist die Bibliothek startklar, und wir können mit der Konfiguration des WireMock-Servers beginnen. Ein einfaches Beispiel in C# ist in Listing 1 zu sehen. In diesem Beispiel wird ein WireMock-Server auf Port 9091 erstellt, der auf GET-Anfragen an /example mit einer einfachen JSON-Antwort reagiert.
Listing 1: Die initiale Konfiguration eines WireMock-Servers
<span class="hljs-keyword">using</span> WireMock.<span class="hljs-built_in">Server</span>;<br/><span class="hljs-keyword">using</span> WireMock.RequestBuilders;<br/><span class="hljs-keyword">using</span> WireMock.ResponseBuilders;<br/><span class="hljs-keyword">using</span> WireMock.Settings;<br/><span class="hljs-built_in">Console</span>.WriteLine(<span class="hljs-string">"WireMock.NET Demo Start"</span>);<br/>var server = <br/> WireMockServer.Start(<span class="hljs-keyword">new</span> WireMockServerSettings<br/>{<br/> Port = <span class="hljs-number">9091</span><br/>});<br/>server.Given(Request.Create().WithPath(<span class="hljs-string">"/example"</span>)<br/> .UsingGet()).RespondWith(Response.Create()<br/> .WithStatusCode(<span class="hljs-number">200</span>).WithBody( <br/> @<span class="hljs-string">"{ "</span><span class="hljs-string">"message"</span><span class="hljs-string">": "</span><span class="hljs-string">"Hello world!"</span><span class="hljs-string">" }"</span>));<br/><span class="hljs-built_in">Console</span>.WriteLine($<span class="hljs-string">"WireMock Server running at "</span> +<br/> <span class="hljs-string">"{server.Urls[0]}"</span>);
Das Bild 1 verdeutlicht über Postman [3], dass diese paar Zeilen Code schon ausreichen, um einen Server zu definieren, der auf eine Anfrage eine vordefinierte Antwort liefert. Welche Konzepte und Funktionen dahinterstecken, beschreibt der gleichnamige Abschnitt weiter unten im Artikel.
Der Postman-Aufruf des ersten Demo-Mocks (Bild 1)
Autor
WireMock.NET hat Abhängigkeiten zu anderen .NET-Bibliotheken, die automatisch über NuGet verwaltet werden. Zu diesen gehören unter anderem Newtonsoft.Json für die JSON-Verarbeitung und Microsoft.AspNetCore.Http für die HTTP-Funktionalität. Die Installation der Bibliothek löst diese Abhängigkeiten automatisch auf und installiert sie mit.Die Bibliothek ist unter der MIT-Lizenz veröffentlicht und kann damit kostenlos in kommerziellen und nichtkommerziellen Projekten zum Einsatz kommen. Die sehr permissive MIT-Lizenz setzt wenig Einschränkungen hinsichtlich der Wiederverwendung des Codes. Die Bibliothek ist kompatibel mit verschiedenen .NET-Versionen einschließlich .NET Core und .NET Framework. Dies macht sie vielseitig einsetzbar in unterschiedlichen Entwicklungsprojekten, unabhängig davon, ob es sich um Desktop-Anwendungen, Webdienste oder andere Arten von .NET-Anwendungen handelt.Der Hauptentwicklungsort für WireMock.NET ist GitHub. Das Repository enthält den Quellcode, Issue-Tracking und Dokumentation. WireMock.NET wurde ursprünglich von Stef Heyenrath entwickelt und wird nun von einer Gruppe von Mitwirkenden gepflegt. Bei Abfassung des Artikels ist Version 1.5.47 von Ende Januar 2024 aktuell.
Weitere Pakete
Neben der Kernbibliothek von WireMock.NET existieren noch zusätzliche Pakete und Erweiterungen, die die Funktionalität der Bibliothek erweitern oder die Integration in bestimmte Entwicklungsumgebungen und Testframeworks vereinfachen. Einige dieser zusätzlichen Pakete und Erweiterungen sind die folgenden:- WireMock.Net.StandAlone: Ein Paket, das es ermöglicht, WireMock.NET als eigenständigen Mock-Server zu betreiben, ohne dass es in eine .NET-Anwendung eingebettet werden muss. Dies ist besonders nützlich für Szenarien, in denen Mock-Services unabhängig von der Hauptanwendung entwickelt, getestet oder bereitgestellt werden sollen.
- WireMock.Net.AspNetCore: Eine Erweiterung für die Integration von WireMock.NET in ASP.NET-Core-Projekte. Dieses Paket erleichtert die Nutzung von WireMock.NET in der ASP.NET-Core-Umgebung, indem es spezifische Konfigurationsoptionen und Middleware-Komponenten bereitstellt, die für eine nahtlose Integration sorgen.
- WireMock.Net.Client: Ein Client-Paket, das die Interaktion mit einem WireMock-Server über eine .NET-Anwendung ermöglicht. Dies kann nützlich sein, um WireMock-Server dynamisch zu konfigurieren oder Testdaten während der Laufzeit zu manipulieren.
- WireMock.Net.Proxy: Ein Paket, das zusätzliche Funktionen für das Proxying von Anfragen durch den WireMock-Server bietet. Dies ist nützlich, um echte HTTP-Anfragen an einen Backend-Service weiterzuleiten und gleichzeitig bestimmte Anfragen mocken oder aufzeichnen zu können.
- WireMock.Net.DependencyInjection: Ein Paket, das Unterstützung für die Dependency Injection von WireMock.NET in .NET-Projekte bietet. Dies erleichtert die Konfiguration und Verwaltung von WireMock-Servern in Projekten, die das Dependency-Injection-Modell verwenden.
Konzepte und Features
WireMock.NET bietet Softwareentwicklern eine breite Palette an Funktionen für das Erstellen und Verwalten von HTTP-Mocks. Die Grundlage von WireMock.NET bildet das Erstellen von Mocks für HTTP-Anfragen. Ein Mock in diesem Kontext ist eine vordefinierte Antwort, die der Server gibt, wenn eine bestimmte Anfrage gestellt wird. Die Erstellung eines Mocks erfolgt in zwei Schritten:- Definieren der Anfrage: Hier ist festgelegt, welche Anfragen von einem Mock-Server abgefangen werden sollen. Dies kann auf der Grundlage unterschiedlicher Kriterien erfolgen, zum Beispiel dem URL, der HTTP-Methode oder spezifischen Anfrage-Headern.
- Spezifizieren der Antwort:Nachdem die Anfrage definiert ist, ist die Antwort des Mock-Servers zu bestimmen. Dies umfasst den HTTP-Statuscode, Antwort-Header und den Antwort-Body.
- URL Matching: Dies ist die häufigste Form des Matchings. Es lassen sich exakte URLs oder Muster, beispielsweise mittels RegEx, definieren, um Anfragen zu matchen.
- HTTP-Methoden: Mocks lassen sich für spezifische HTTP-Methoden wie etwa GET, POST, PUT, DELETE erstellen.
- Header und Body-Inhalte: Auch das Matching auf Basis von Anfrage-Headern oder spezifischen Body-Inhalten ist möglich. Dies ist nützlich, um verschiedene Szenarien zu testen, die von diesen Parametern abhängen.
- HTTP-Statuscodes:Jeder HTTP-Statuscode lässt sich als Antwort definieren, von 200 (OK) bis 500 (Internal Server Error), um verschiedene Szenarien zu simulieren.
- Antwort-Header: Um das Verhalten des zu testenden Systems bei verschiedenen Arten von Antworten zu beurteilen, ist die Definition beliebiger Antwort-Header möglich.
- Antwort-Body: Der Antwort-Body lässt sich festlegen, um bestimmte Daten zurückzugeben. Dies können einfacher Text, JSON, XML oder andere Inhaltsformate sein.
- Delays: Durch die Definition von künstlichen Verzögerungen ist es möglich, das Verhalten eines Systems unter Bedingungen langsamer Netzwerkantworten zu testen.
- Fehler-Simulation: Darüber hinaus ist es möglich, fehlerhafte Antworten zu simulieren, um zu sehen, wie eine Anwendung auf verschiedene Fehlerzustände, beispielsweise auf Netzwerkfehler oder Serverausfälle, reagiert.
- Proxying: WireMock.NET lässt sich so konfigurieren, dass Anfragen an einen echten Server weitergeleitet und die Antworten zurück an den Client gesendet werden. Dies ist nützlich, um reale Antworten in Tests einzubeziehen und gleichzeitig bestimmte Anfragen zu mocken.
Listing 3: Das allgemeine Schema, um einen Mock-Server inklusive Request und Response zu erstellen
var <span class="hljs-built_in">server</span> = WireMockServer.Start(<br/> <span class="hljs-keyword">new</span> WireMockServerSettings<br/>{<br/> Port = <span class="hljs-number">8080</span><br/>});<br/><span class="hljs-built_in">server</span>.Given(<span class="hljs-built_in">Request</span><br/> .Create()...).RespondWith(<span class="hljs-built_in">Response</span>.Create()...); 
Der Aufruf der fiktiven Wetter-Route (Bild 2)
Autor
Weitere praktische Beispiele
Die Einrichtung eines einfachen Mock-Servers mit WireMock.NET hat die initiale Konfiguration bereits gezeigt. Neben einer Server-Instanz mit einem Port sind eine Request- und eine Response-Definition notwendig. Das Listing 3 verdeutlicht dieses Schema noch einmal.Listing 2: Ein Mock-Server für eine API-Route
<span class="hljs-built_in">server</span>.Given(<span class="hljs-built_in">Request</span>.Create().WithPath(<br/> <span class="hljs-string">"/wetter/heute"</span>).UsingGet())<br/> .RespondWith(<span class="hljs-built_in">Response</span>.Create()<br/> .WithStatusCode(<span class="hljs-number">200</span>)<br/> .WithHeader(<span class="hljs-string">"Content-Type"</span>, <span class="hljs-string">"application/json"</span>)<br/> .WithBody(@<span class="hljs-string">"{ ""temperatur"": ""22°C"", </span><br/><span class="hljs-string"> ""bedingungen"": ""sonnig"" }"</span>));
Ein typisches Beispiel für eine solche Konfiguration ist der Test eines RESTful API. Angenommen, wir entwickeln eine Anwendung, die Daten von einem solchen REST-API abruft, dann zeigt das Beispiel in Listing 4, wie eine mögliche Anfrage inklusive Antwort konfiguriert werden kann. Im Beispiel ist ein Mock-Server konfiguriert, der auf GET-Anfragen an
/api/produkte mit einer JSON-Antwort reagiert, die eine Liste von Produkten enthält. Da diese Produkte im Code definiert sind, ist es problemlos möglich, diese ebenfalls zu randomisieren, um sehr unterschiedliche Daten zu testen. Eine andere Möglichkeit ist, diese Produktdaten aus vorgefertigten Ressourcen zu laden, um spezifische Testfälle nacheinander abzuarbeiten.
/api/produkte mit einer JSON-Antwort reagiert, die eine Liste von Produkten enthält. Da diese Produkte im Code definiert sind, ist es problemlos möglich, diese ebenfalls zu randomisieren, um sehr unterschiedliche Daten zu testen. Eine andere Möglichkeit ist, diese Produktdaten aus vorgefertigten Ressourcen zu laden, um spezifische Testfälle nacheinander abzuarbeiten.
Listing 4: Ein gemockter API-Aufruf für fiktive Produkte
<span class="hljs-built_in">server</span>.Given(<span class="hljs-built_in">Request</span>.Create().WithPath(<br/> <span class="hljs-string">"/api/produkte"</span>).UsingGet())<br/> .RespondWith(<span class="hljs-built_in">Response</span>.Create()<br/> .WithStatusCode(<span class="hljs-number">200</span>)<br/> .WithHeader(<span class="hljs-string">"Content-Type"</span>, <span class="hljs-string">"application/json"</span>)<br/> .WithBody(@<span class="hljs-string">"[{ ""id"": 1, ""name"": </span><br/><span class="hljs-string"> ""Produkt A"" }, { ""id"": 2, ""name"": </span><br/><span class="hljs-string"> ""Produkt B"" }]"</span>));
WireMock.NET ermöglicht es zudem, Fehlerzustände und Netzwerkausfälle zu simulieren. Dies ist besonders nützlich, um die Widerstandsfähigkeit einer Anwendung zu testen. Das Listing 5 zeigt dazu den Code, um einen HTTP-Code 500 auf eine Anfrage zurückzugeben. Das Ergebnis dieser Abfrage in Postman zeigt das Bild 3. In diesem Beispiel antwortet der Mock-Server auf Anfragen an /api/fehler mit einem 500-Serverfehler, was es ermöglicht, das Verhalten der Anwendung in diesem konkreten Fehlerfall zu testen.
Listing 6: Beispielhafte Einbindung von WireMock.NET in einen Unit-Test
<span class="hljs-keyword">namespace</span> <span class="hljs-title">MeineApp.Tests</span><br/>{<br/> [TestFixture]<br/> <span class="hljs-keyword">public</span> <span class="hljs-keyword">class</span> <span class="hljs-title">MeineApiTests</span><br/> {<br/> <span class="hljs-keyword">private</span> WireMockServer _server;<br/> [SetUp]<br/> <span class="hljs-function"><span class="hljs-keyword">public</span> <span class="hljs-keyword">void</span> <span class="hljs-title">Setup</span>(<span class="hljs-params"></span>)</span><br/><span class="hljs-function"> </span>{<br/> server = WireMockServer.Start();<br/> server.Given(Request.Create().WithPath(<br/> <span class="hljs-string">"/api/meinendpoint"</span>).UsingGet())<br/> .RespondWith(Response.Create()<br/> .WithStatusCode(<span class="hljs-number">200</span>).WithBody(<span class="hljs-string">"Testantwort"</span>));<br/> }<br/> [Test]<br/> <span class="hljs-function"><span class="hljs-keyword">public</span> <span class="hljs-keyword">void</span> <span class="hljs-title">ApiTest</span>(<span class="hljs-params"></span>)</span><br/><span class="hljs-function"> </span>{<br/> <span class="hljs-comment">// Testcode using the mocked server...</span><br/><span class="hljs-comment"> }</span><br/><span class="hljs-comment"> [TearDown]</span><br/><span class="hljs-comment"> public void TearDown()</span><br/><span class="hljs-comment"> {</span><br/><span class="hljs-comment"> server.Stop();</span><br/><span class="hljs-comment"> }</span><br/><span class="hljs-comment"> }</span><br/><span class="hljs-comment">}</span> 
Der Test einer absichtlich fehlerhaften API-Route in Postman (Bild 3)
Autor
WireMock.NET lässt sich nahtlos in bestehende .NET-Projekte integrieren. Listing 6 zeigt ein Beispiel eines NUnit-Testprojekts, in dem ein WireMock-Server für jeden Test initialisiert und nach dem Test wieder heruntergefahren wird. Der Server ist so konfiguriert, dass er auf bestimmte Anfragen während der Testausführung reagiert.
Listing 7: Ein Mock für eine API-Route inklusive Parameter
<span class="hljs-built_in">server</span>.Given(<span class="hljs-built_in">Request</span>.Create()<br/> .WithPath(<span class="hljs-string">"/api/kunde"</span>).UsingGet()<br/> .WithParam(<span class="hljs-string">"id"</span>, <span class="hljs-keyword">new</span> RegexMatcher(@<span class="hljs-string">"\d+"</span>)))<br/> .RespondWith(<span class="hljs-built_in">Response</span>.Create()<br/> .WithBody(<span class="hljs-string">"{{request.query.id}}: Kunde gefunden"</span>)<br/> .WithTransformer());
Diese Beispiele verdeutlichen, wie WireMock.NET zum Einsatz kommen kann, um robuste und zuverlässige Tests für .NET-Anwendungen zu erstellen. Durch das Simulieren von externen Abhängigkeiten ermöglicht es WireMock.NET, verschiedene Szenarien zu testen, ohne auf echte externe Dienste oder APIs angewiesen zu sein. Dies erleichtert nicht nur das Testen, sondern steigert auch die Qualität insgesamt.
Erweiterte Funktionen und Techniken
WireMock.NET bietet eine Vielzahl von erweiterten Funktionen, die komplexere Testszenarien und eine genauere Steuerung des Mock-Verhaltens ermöglichen. Diese fortgeschrittenen Techniken erlauben es, realistischere und dynamischere Mock-Umgebungen zu schaffen. Im Folgenden werden einige dieser Techniken mit C#-Beispielen vorgestellt.Response Templating ist eine leistungsfähige Funktion von WireMock.NET, die es ermöglicht, dynamische Antworten basierend auf der Anfrage zu generieren. Dies wird oft verwendet, um realistischere Mock-Services zu erstellen, die auf unterschiedliche Anfragen variabel reagieren können. Das Listing 7 zeigt dazu ein Beispiel. Das Ergebnis über Postman zeigt das Bild 4.Listing 5: Beispiel für den Mock eines HTTP-500-Fehlers
<span class="hljs-built_in">server</span>.Given(<span class="hljs-built_in">Request</span>.Create().WithPath(<br/> <span class="hljs-string">"/api/fehler"</span>).UsingGet())<br/> .RespondWith(<span class="hljs-built_in">Response</span>.Create().WithStatusCode(<span class="hljs-number">500</span>)<br/> .WithBody(<span class="hljs-string">"Interner Serverfehler"</span>)); 
Der Aufruf der dynamischen API-Route mit Postman (Bild 4)
Autor
In diesem Beispiel wird ein Mock-Server eingerichtet, der auf GET-Anfragen an /api/kunde reagiert und den Wert des id-Parameters in der Antwort zurückgibt. Wenn also eine Anfrage mit /api/kunde?id=1234 gesendet wird, antwortet der Server mit „1234 Kunde gefunden“. Wird keine Zahl übergeben, schlägt der RegEx-Mapper nicht an und es erscheint die Fehlermeldung:
{
“Status”: “No matching mapping found”
}
Stateful Behavior ermöglicht es, das Verhalten des Mock-Servers auf der Grundlage des aktuellen Zustands zu ändern. Das ist besonders dann nützlich, wenn komplexere Interaktionen simuliert werden sollen, wie sie in echten Anwendungen häufig vorkommen. Ein Beispiel dazu zeigt das Listing 8. Hier wird ein Szenario erstellt, in dem der Server seinen Zustand basierend auf den eingehenden Anfragen ändert. Anfangs antwortet der Server mit „Nicht angemeldet“, wechselt dann aber in den Zustand „Angemeldet“ und antwortet entsprechend.
Listing 8: Zwei Mocks für die Simulation eines Statuswechsels
<span class="hljs-selector-tag">server</span><span class="hljs-selector-class">.Given</span>(Request.Create().WithPath(<span class="hljs-string">"/api/status"</span>)<br/> .UsingGet())<br/> <span class="hljs-selector-class">.InScenario</span>(<span class="hljs-string">"Statuswechsel"</span>)<br/> <span class="hljs-selector-class">.WillSetStateTo</span>(<span class="hljs-string">"Angemeldet"</span>)<br/> <span class="hljs-selector-class">.RespondWith</span>(Response.Create().WithBody(<br/> <span class="hljs-string">"Nicht angemeldet"</span>));<br/><span class="hljs-selector-tag">server</span><span class="hljs-selector-class">.Given</span>(Request.Create().WithPath(<span class="hljs-string">"/api/status"</span>)<br/> .UsingGet())<br/> <span class="hljs-selector-class">.InScenario</span>(<span class="hljs-string">"Statuswechsel"</span>)<br/> <span class="hljs-selector-class">.WhenStateIs</span>(<span class="hljs-string">"Angemeldet"</span>)<br/> <span class="hljs-selector-class">.RespondWith</span>(Response.Create().WithBody(<br/> <span class="hljs-string">"Angemeldet"</span>));
Die Record-und-Playback-Funktion von WireMock.NET ist nützlich, um reale API-Antworten aufzuzeichnen und diese später in Tests zu verwenden. Dies ist besonders hilfreich, wenn komplexe APIs im Einsatz sind, deren Verhaltensweisen schwierig manuell zu mocken sind. Das Snippet in Listing 9 zeigt, wie eine Aufzeichnung gestartet und gestoppt wird. Die aufgezeichneten Daten lassen sich anschließend für zukünftige Tests wiederverwenden.
Listing 9: Beispiel für das Aufzeichnen von API-Aufrufen für die spätere Nutzung
var server = WireMockServer.Start();<br/>server.StartRecording(<span class="hljs-string">"http://echte-api.com"</span>);<br/><span class="hljs-regexp">//</span> Ausführen von realen Anfragen an das echte API<br/><span class="hljs-regexp">//</span> ...<br/><span class="hljs-regexp">//</span> Stoppen des Recordings und Speichern der Anfragen<span class="hljs-regexp">/</span><br/><span class="hljs-regexp">/</span><span class="hljs-regexp">/ Antworten</span><br/><span class="hljs-regexp">server.StopRecording();</span>
Diese fortgeschrittenen Funktionen von WireMock.NET erweitern die Möglichkeiten für das Testen von Software erheblich. Durch die Verwendung dynamischer Antwortvorlagen, zustandsabhängiger Mocks und der Fähigkeit, echte API-Antworten aufzuzeichnen und wiederzuverwenden, lassen sich realistischere und anspruchsvollere Testumgebungen schaffen.
Integrationstests mit WireMock.NET
Integrationstests spielen eine entscheidende Rolle in der Softwareentwicklung. Sie überprüften die korrekte Interaktion zwischen verschiedenen Modulen und externen Diensten einer Anwendung. WireMock.NET bietet eine effiziente Lösung, um externe HTTP/HTTPS-Dienste zu mocken, was eine isolierte und kontrollierbare Testumgebung für Integrationstests ermöglicht. Durch die Simulation externer Abhängigkeiten mit WireMock.NET lässt sich sicherstellen, dass die Integrationstests konsistent und unabhängig von externen Faktoren durchgeführt werden.WireMock.NET ermöglicht es, externe Services zu isolieren, indem es deren Verhalten in einer Testumgebung nachbildet. Dies reduziert die Variabilität in Tests und verbessert die Reproduzierbarkeit der Ergebnisse. Externe Abhängigkeiten sind nicht immer zugänglich oder stabil. Durch das Mocking dieser Dienste mit WireMock.NET lassen sich Tests jederzeit durchführen, ohne auf externe Services angewiesen zu sein. Das Beispiel aus Listing 10 zeigt die Kombination von WireMock.NET und xUnit.Listing 10: Ein Integrationstest mit xUnit
public class WetterServiceTest<br/>{<br/> [Fact]<br/> public void WetterService_RuftDatenAb_KeinFehler()<br/> {<br/> <span class="hljs-regexp">//</span> Einrichten des WireMock-Servers<br/> var server = WireMockServer.Start();<br/> server.Given(Request.Create().WithPath(<br/> <span class="hljs-string">"/wetter/today"</span>).UsingGet())<br/> .RespondWith(Response.Create()<br/> .WithStatusCode(<span class="hljs-number">200</span>)<br/> .WithBody(@<span class="hljs-string">"{"</span><span class="hljs-string">"temperatur"</span><span class="hljs-string">": "</span><span class="hljs-string">"22°C"</span><span class="hljs-string">"}"</span>));<br/> <span class="hljs-regexp">//</span> Konfigurieren der Anwendung, um den <br/> <span class="hljs-regexp">//</span> Mock-Server zu verwenden<br/> var wetterService = new WetterService(<br/> server.Urls[<span class="hljs-number">0</span>] + <span class="hljs-string">"/wetter/today"</span>);<br/> <span class="hljs-regexp">//</span> Ausführen der Methode, die getestet werden <br/> <span class="hljs-regexp">//</span> soll<br/> var wetter = wetterService.RufeWetterdatenAb();<br/> <span class="hljs-regexp">//</span> Überprüfen, ob die Methode wie erwartet <br/> <span class="hljs-regexp">//</span> funktioniert<br/> Assert.Equal(<span class="hljs-string">"22°C"</span>, wetter.Temperatur);<br/> <span class="hljs-regexp">//</span> Aufräumen<br/> server.Stop();<br/> }<br/>} Best Practices und Tipps
Die effektive Nutzung von WireMock.NET in Testumgebungen, Performance-Optimierung und das Management von Ressourcen sowie die Berücksichtigung von Sicherheitsaspekten sind essenziell, um die Vorteile dieses Tools vollständig auszuschöpfen. Im Folgenden werden einige Best Practices und hilfreiche Tipps für den Umgang mit WireMock.NET dargelegt.WireMock.NET sollte zum Einsatz kommen, um isolierte Testumgebungen zu schaffen, die externe Abhängigkeiten simulieren. Dies gewährleistet, dass Tests konsistent und reproduzierbar sind, unabhängig von der Verfügbarkeit oder dem Zustand externer Services. Auch wenn WireMock.NET darauf ausgelegt ist, effizient zu sein, ist die Ressourcennutzung, wie zum Beispiel Speicher und die CPU-Auslastung, im Blick zu behalten, besonders wenn eine große Anzahl von Mocks oder komplexe Simulationen zum Einsatz kommen.Zudem sollten wir es vermeiden, unnötig große Datenmengen in Mock-Antworten zu verwenden, da dies die Testperformance beeinträchtigen kann. Stattdessen sind repräsentative Daten zu bevorzugen, die für die Testfälle relevant sind. Wenn möglich, ist auf die parallele Ausführung von Tests zu achten, um die Testlaufzeiten zu verkürzen. Wir müssen aber sicherstellen, dass dies nicht zu Konflikten innerhalb der simulierten Umgebungen führt.Vergleich mit anderen Projekten
Neben WireMock.NET existieren andere Projekte und Bibliotheken, die ähnliche Funktionalitäten bieten und in bestimmten Szenarien als Alternativen oder Ergänzungen zu WireMock.NET eingesetzt werden können:- MockServer [4] ist ein vielseitiges Tool, das nicht nur für .NET, sondern auch für andere Programmiersprachen wie Java und Node.js verfügbar ist. Es ermöglicht das Mocking von HTTP- und HTTPS-Anfragen sowie das Erstellen von Erwartungen, die in einer Vielzahl von Testszenarien verwendet werden können. MockServer unterstützt auch die Aufzeichnung und Wiedergabe von Anfragen, was die Erstellung von Mocks aus realen Daten erleichtert.
- Mountebank [5] bietet sprachunabhängige Mocking-Funktionalitäten, die eine breite Palette von Entwicklungsumgebungen unterstützen. Es ist bekannt für seine Fähigkeit, auch Nicht-HTTP-Protokolle wie TCP und SMTP zu mocken, was es zu einer vielseitigen Wahl für komplexe Testumgebungen macht. Mountebank betont die Bedeutung von Testisolation und ermöglicht es Entwicklern, Dienste zu simulieren, ohne externe Abhängigkeiten einzubinden.
- Postman [3], ein weit verbreitetes Tool für die Entwicklung und das Testen von APIs, ermöglicht es auch, Mock-Server zu erstellen. Obwohl Postman hauptsächlich als API-Entwicklungsumgebung bekannt ist, ermöglichen seine Mock-Server-Funktionen das Simulieren von API-Antworten, was die Entwicklung und das Testen von Frontend-Anwendungen erleichtert, die auf diese APIs angewiesen sind.
- Pact [6] ist ein Framework, das sich auf das Testen von API-Integrationen konzentriert, indem es Verträge zwischen Servicekonsumenten und -anbietern erstellt und validiert. Pact unterstützt mehrere Programmiersprachen und Plattformen und ermöglicht es sicherzustellen, dass APIs wie erwartet funktionieren, basierend auf den definierten Verträgen. Pact ist besonders nützlich in Microservices-Architekturen, wo die Interaktionen zwischen Diensten genau definiert und getestet werden müssen.
- NSubstitute [7] for http ist eine spezialisierte Bibliothek für .NET, die das Mocking von HTTP-Anfragen für Tests vereinfacht. Es arbeitet nahtlos mit HttpClient zusammen und bietet eine einfache Syntax für das Definieren von Mock-Antworten. NSubstitute for http eignet sich ideal für Entwickler, die bereits NSubstitute in ihren Projekten verwenden und eine konsistente Mocking-Erfahrung für HTTP-Anfragen wünschen.
Fazit
Durch seine umfassenden Möglichkeiten zum Mocking und Simulieren von HTTP/HTTPS-Services etabliert sich WireMock.NET als unverzichtbares Instrument in der .NET-Community. Dieses Tool erlaubt es, komplexe Mocking-Szenarien effektiv zu realisieren und präzise auf Testanforderungen zuzuschneiden. Die flexible und erweiterbare Konzeption von WireMock.NET unterstützt die Erstellung realistischer Testumgebungen durch präzises Request Matching und die Generierung dynamischer Antworten.Die Vielseitigkeit von WireMock.NET zeigt sich in der breiten Palette seiner Anwendungsmöglichkeiten. Von der Einrichtung einfacher Mock-Server bis hin zu fortgeschrittenen Szenarien wie der Simulation von Netzwerkausfällen und der Implementierung zustandsabhängiger Mocks deckt WireMock.NET eine Vielzahl von Einsatzmöglichkeiten ab. Diese Anwendungen demonstrieren, wie WireMock.NET in unterschiedlichen Phasen der Softwareentwicklung und bei diversen Teststrategien eingesetzt werden kann, um die Qualität und Zuverlässigkeit von Softwareprodukten zu steigern.Die Einordnung von WireMock.NET im Vergleich zu anderen verfügbaren Mocking-Tools verdeutlicht zudem, dass seine spezielle Ausrichtung auf die .NET-Plattform und die umfangreichen Mocking-Fähigkeiten es zu einer ausgezeichneten Wahl für .NET-Entwickler machen.WireMock.NET ist daher nicht nur ein Werkzeug, sondern ein integraler Bestandteil des Testökosystems, der entscheidend zur Entwicklung robuster und fehlerresistenter Anwendungen beiträgt. Die Bibliothek lässt sich schnell in eigene Projekte integrieren, die Dokumentation ist gut, und die Implementierung von Testfällen gestaltet sich unkompliziert. Insgesamt bietet WireMock.NET einen lohnenden Einstieg in die Welt des Mockings und verdient sich durch den einfachen Einsatz und die zahlreichen Funktionen ein „Sehr gut“ und eine klare Empfehlung.Fussnoten
- Das GitHub-Repository zu WireMock.NET, http://www.dotnetpro.de/SL2404Frameworks1
- Die Projektseite zu WireMock, https://wiremock.org
- Die Website zu Postman, http://www.postman.com
- Die Website zum Projekt MockServer, http://www.mock-server.com
- Die Projektseite zu Mountebank, http://www.mbtest.org
- Die Website zum Framework Pact, https://pact.io
- Das Repository zu NSubstitute auf GitHub, http://www.dotnetpro.de/SL2404Frameworks2
