Rest-Assured ist eine Java Bibliothek, die das Schreiben von (Integrations-)Tests gegen REST-API’s ermöglicht. Insbesondere im Bereich der Microservices (z.B. Internet of Things) spielen Restful Webservices eine zunehmend große Rolle.
Aber was bringt uns eigentlich Rest-Assured?

Use Cases

Stellen Sie sich eine Anwendung wie eine Web-Anwendung für Finanz-Investoren vor. Diese stellt unterschiedlichste Daten dar, z.B. die Aktienkurse an der Wall-Street, den Nikkei225 oder Preise für Gold, Silber und Platin an den verschiedenen Rohstoffbörsen der globalen Märkte.
Woher kommen diese Daten, technisch gesehen? Sie werden über die API´s der jeweiligen Provider abgefragt und über die Logik der jeweiligen Web-Anwendung interpretiert bzw. über deren Designs dargestellt.
Wie gehen wir aber vor, wenn wir solche Provider-Services testen wollen, lange bevor überhaupt ein User Interface implementiert wurde? Hier kommen Frameworks wie Rest-Assured ins Spiel. API-Testing wird immer wichtiger und eine Automatisierung, gerade vor dem Hintergrund schneller Entwicklungszyklen, macht Sinn.
Rest-Assured ermöglicht es, mit einem gewissen Java-Basiswissen, die Funktionalität des Backends im Rahmen der Integrationstests zu sichern, während das Front-End Testing sich tatsächlich auf die Funktionalität der UI und Clientseitiger Operationen konzentrieren kann.

Rest-Assured in der Praxis

Rest-Assured lehnt sich an die, ggf. auch aus dem Bereich des BDD gewohnte, Logik an und definiert ein Grundgerüst von drei Schritten mit ‚GIVEN‘, ‚WHEN‘ und ‚THEN‘. Dieses Entwurfsmuster wird oft auch AAA-Muster genannt. AAA steht in diesem Kontext als Akronym für ‚ARRANGE‘ (entspricht GIVEN), ‚ACT‘ (WHEN) und ‚ASSERT‘ (THEN) und definiert die drei logischen Grundschritte eines Workflows zum Testen einer REST-Schnittstelle.

Es handelt sich dabei um eine Abstraktionsschicht, die letztlich einem sog. „Fluent-Interface“ entspricht, ein Konzept, das von Eric Evans und Martin Fowler vorgeschlagen wurde (Fow 2022) . Das entbindet uns von den Belangen auf der Low-Level-Code Ebene. Dieses Interface ermöglicht uns mittels des sog. „Method-Chaining“ (.given().when().then()) einen Request zu spezifizieren und zu erzeugen, abzusenden und schließlich zu verifizieren, ohne uns um die Funktionsweise unter der Haube kümmern zu müssen. Dabei nutzen wir eine Terminologie die weitestgehend selbsterklärend ist, wenn man weiß was man machen möchte.

Der REST-Assured Test-Workflow – Arrange, Act and Assert

Soviel zur Theorie, aber welche konkreten Möglichkeiten bieten uns die oben genannten AAA-Methoden eigentlich? Um etwas Licht in die Sache zu bringen, schauen wir uns die drei Bereiche unseres Test-Workflows etwas genauer an.
– given() – „ARRANGE“-Step: Der Header (Nachrichtenkopf), der Informationen über den Nachrichtenrumpf enthält, und Nutzdaten (Nachrichtenrumpf) werden über diese Methode an unseren Request übergeben. Hierfür werden über given() per Punktnotation weitere Methoden aufgerufen, die z.B. den Content-Type oder Kodierung übergeben oder die eigentlichen Nutzdaten.
– when() – „ACT“-Step: Hier wird der eigentliche Request gemacht. Auch hier lassen sich per Punktnotation über die when()-Methode weitere Methoden aufrufen, so lassen sich z.B. die http-Anfragemethode (POST, GET, PUT…) oder die Endpunkt-URL spezifizieren und schliesslich der Request anstossen.
– then() – „ASSERT“-Step: In diesem Schritt lassen sich die Verifikationen durchführen, wie z.B. die Prüfung des Response-Codes oder verschiedene Plausibilitätsprüfungen gegen die Nutzdaten der Response.

An dieser Stelle kennen wir also die Grundsätzliche Struktur des Workflows zur Implementierung eines Rest-Assured API-Testfalles und haben die wichtigsten Substeps des Workflows skizziert. Im Rahmen dieses Artikels bleibt also nur noch ein Konkretes Beispiel in Java.

Rest-Assured API-Testfall

In der Abbildung 1 sehen wir einen vollständigen API-Testfall in validem Java-Code. Die eingerückten Methodenaufrufe stellen hierbei die Substeps der übergeordneten Steps (given, when, then) dar.
Es handelt sich um einen http Get-Request, der exemplarisch eine Liste von Produkten abfragt. Die Liste kommt im Response-Body in JSON-Format zurück, wie im Content-Type im GIVEN-Step spezifiziert.
Der WHEN-Step spezifiziert die http-Methode (get()-Methode in Rest-Assured) und triggert den Request.
Abschließend werden im THEN-Step zwei Verifikationen gemacht. Die Prüfung des Status Code 200 und die Prüfung der Anzahl der Listenelemente. Hierfür nutzen wir einen Hamcrest-Matcher. Hamcrest (Ham, 2022) ist ein verbreitetes Java Framework, das man im Unit-Test Bereich einsetzt und das uns eine Reihe von vorgefertigten Prädikaten zur Verfügung stellt.

Abbildung - Rest-Assured-Codebeispiel

Abb. 1 – Rest-API Get-Request

 

Für weitere Funktionalitäten sei an dieser Stelle auf die offizielle Doku verwiesen (Jdoc 2022).

Quellen:

Jdoc 2022 – Java Dokumentation, 2022-11-11, https://javadoc.io/doc/io.rest-assured/rest-assured/latest/index.html

Ham 2022 – Hamcrest Project Website, 2022-11-14, https://hamcrest.org/JavaHamcrest/

Fow 2022, Martin Fowler – Webpräsenz, 2022-11-14, https://martinfowler.com/bliki/FluentInterface.html

Verwandte Themen:

BDD

REST-API

Hamcrest

SOA-Services

Swagger