5. Juni 2018
Neco Giedrojc
0

Mocks in der Testumgebung Teil 1

Die Komplexität und Interaktion der Softwareanwendungen, die in Unternehmen eingesetzt wird, ist in den letzten Jahren stark gestiegen. Werden heute Releases ausgerollt, steht ein Teil der neuen Funktionen immer im Zusammenhang mit dem Datenaustausch zu anderen Anwendungen. Das merken wir auch im Bereich Softwaretest: Der Fokus der Tests hat sich von reinem Systemtest auf den Bereich der Integrationstests erweitert. Darum kommen auch Mocks zum Einsatz.

Wir arbeiten in einem Testcenter und führen für unsere Kunden den übergreifenden Integrationstest über seine komplexe Anwendungsinfrastruktur durch. Daher bauen wir die Testumgebungen passend zur Produktivumgebung auf. Also wozu brauchen wir dann Mocks, wenn die Integrationstestumgebung bereits alle Software-Komponenten besitzen?
Zum Teil liegt man mit dieser Denkweise schon richtig, allerdings werden auf den unterschiedlichen Staging-Ebenen beim Test verschiedene Fokusse gesetzt. Mocks werden im Systemtest eher weniger verwendet, da in diesem Bereich die Funktionen der Software getestet werden. Dafür werden Mocks häufiger in Integrationstest verwendet. Da es aber nicht immer möglich ist, den kompletten Nachrichtenfluss zu testen, wird als Alternative die Kommunikation an der Schnittstelle geprüft.

Werden im Integrationstest 3 Komponenten getestet, die im Nachrichtenfluss direkt hintereinanderliegen, kann bei Verwendung aller 3 Softwarekomponenten nicht hundertprozentig sichergestellt werden, dass die Prozedur ohne Probleme läuft. Es könnte sein, dass die jeweiligen Fehler der Komponenten den Nachrichtenfluss verfälschen und im Nachhinein wieder richtiggestellt wird, der Fehler quasi maskiert wird. Daher stellen wir Mocks an die jeweiligen Enden der Komponenten, um gezielte Ein- und Ausgaben zu bekommen.

Um die beschriebenen Probleme und Eigenheiten eines Mocks zu erklären, nutzen wir als zu testende Anwendung einen Rest-Services. Der Rest-Service sollte in der Lage sein, ein GET und ein POST–Befehl durchzuführen. Würde unsere Komponente nun nach personenspezifischen Daten beim Mock nachfragen mit einem GET-Befehl, könnten wir unseren Mock so konfigurieren, dass er standardisierte Antworten zurück gibt oder bei POST-Befehlen einfache Berechnungen durchführt.

Mit Microsoft Visual Studio kam man in C# schnell ein WebAPI-Projekt erstellen, welches die grundlegende Funktion eines Rest-Services besitzt. Die Methoden des Controllers müssen nur noch angepasst werden und man hat eine funktionierende Rest-API zur Verfügung.

Datei > Neu > Projekt > Visual C# > Web > Webanwendung

Wenn man sich die Controller der WebAPI anschaut, kann man sehen, dass bestimmte URLs, Funktionen innerhalb der API aufrufen. In diesem Beispiel wird eine kleine WebAPI verwendet, die als Helden-Datenbank genutzt wird.

 

Mocks in der Testumgebung Teil 1 heldenliste

Mocks in der Testumgebung Teil 1 heldenliste

Die Route beschreibt den URL-Pfad um die HttpGet(GET-Befehl)- oder HttpPost(POST-Befehl) Funktion aufzurufen.

Beispiel: http:localhost/api/helden/add

Sobald man die Rest-API zum Laufen gebracht hat, ist es mit einem API-Tool(Postman) oder einem Browser möglich, unterschiedliche Rest-Befehle an die URL zu schicken. Wenn nun ein POST-Befehl an die Rest-API geschickt wird, nimmt der Service diesen an und erkennt anhand der URL, dass die Funktion AddHeldenDetails() aufgerufen werden soll. Die Funktion nimmt die mitgeschickten Daten auf und fügt sie ihrer Datenbank hinzu. Als Antwort liefert sie den Return-Wert der Funktion. In diesem Fall die Bestätigung über das Hinzufügen des gewünschten Heldes.

POST-Befehl:

POST /api/Helden/zwei HTTP/1.1
Host: localhost:53521
Content-Type: application/x-www-form-urlencoded
Cache-Control: no-cache
Postman-Token: b169b96f-682d-165d-640f-dbcafe52789e
{ „Name“:“Maria“,“Klasse“: „Lord“,“Alter“:68,“Level“:57 }

Antwort:

Der Held mit dem Namen: Maria wurde hinzugefügt

 

Wir haben nun mit unserem POST-Befehl die Heldin Maria der Datenbank hinzugefügt. Nun können mit dem GET-Befehl die gespeicherten Helden abrufen werden. Hier ein Beispiel zum Format des GET-Befehls, welcher an die Rest-API geschickt wird mit der dazugehörigen Antwort der API:

Abfrage:

GET /api/helden/get HTTP/1.1
Host: localhost:53521
Content-Type: application/json
Cache-Control: no-cache
Postman-Token: b3f19b01-11cf-85f1-100f-2cf175a990d9

 

Antwort:

 

Mocks in der Testumgebung Teil 1

Mocks in der Testumgebung Teil 1

In der Antwort ist zusehen, dass die Heldin Maria der Liste hinzugefügt wurde und nun jederzeit abgerufen werden kann.

Nun wissen wir um die Funktionsweise den Rest-Services Bescheid, welcher Input zu welchem Output führt. Mit dieser Information können wir uns dann an den Bau eines Mocks begeben. Mit diesem Thema werde ich mich im nächsten Teil genauer befassen.

Das war „Mocks in der Testumgebung Teil 1“ … Teil 2 folgt 🙂

Neco Giedrojc

Neco Giedrojc schloss sich kurz nach seinem Studienabschluss im Bereich „Computer Engineering“ dem Testbereich der Saxonia Systems AG an und arbeitet dort als Tester. Dabei befasst er sich in seinem Hauptprojekt aktuell mit dem Integrationstest komplexer Systeme.

TeilenTweet about this on TwitterShare on Facebook0Share on Google+0Share on LinkedIn0

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.