Monolithen waren gestern: Microservice Testautomation mit REST Assured

Das Problem mit Monolithen und Continuous Delivery

Einfach veranschaulichen lässt sich das am Beispiel einer Java Anwendung. Im Zuge des Deployments wird hier in vielen Fällen nur eine einzige Datei (EAR oder WAR) ausgeliefert. Sämtliche Module oder Bibliotheken der Anwendung sind darin verpackt.

Und damit kommen wir zum Problem: Mit jeder Änderung muss die Anwendung komplett neu gebaut und natürlich auch getestet werden. Sprich auch jene Teile, die von der Änderung gar nicht betroffen sind, müssen jedes mal die komplette Continuous Delivery Pipeline durchlaufen. Das kostet Zeit, Geld und Ressourcen.

Der Microservice Hype

Die Alternative zur monolithischen Architektur heißt Microservices. Twitter, Netflix, Amazon & Co. setzen schon seit Jahren darauf. Doch was steckt eigentlich dahinter?

Monolithen waren gestern - Automatisches Testen mit Microservices | TestPlus

Microservices bilden einen überschaubaren, oft in sich geschlossenen, Teil einer Anwendung ab. Dabei entstehen viele kleine, getrennt voneinander deploybare, Artefakte mit wenig fachlicher Komplexität.

Das hat zur Folge, dass die Deployment Pipeline nach einer Änderung auch wirklich nur mehr für den geänderten Teil der Anwendung durchlaufen werden muss. Das heißt wir bauen und testen die geänderte Funktion und ersparen uns die unveränderten Teile.

Das REST Assured Framework

Die steigende Popularität von Microservices und im Speziellen RESTful Services haben einige Tools zur Webservice Automation hervorgebracht. Eines der bekanntesten ist wohl  REST Assured von Jayway.

Rest Assured von Jaybay bietet viele Automationsmöglichkeiten. Hier anhand eines einfachen Beispiels: Klick um zu Tweeten

Nehmen wir an die Endpoint Spezifikation unserer API beschreibt ein Service getShoppingCart das uns den Inhalt eines Warenkorbs liefert:

REQUEST

endpoint method
http://localhost/getShoppingCart GET


RESPONSE

status content-type response body
200 application/json {

“items”:

[

{

“id” : “54322”,

“title” : “iPhoneX”,

“amount” : “1”,

“total” : “1349,99”

},

{

“id” : “32149”,

“title” : “magic mouse”,

“amount” : “2”,

“total” : “158,99”

}

]

}

Um das Service automatisiert zu testen, müssen wir REST Assured erstmal in unser Projekt einbinden. Dazu fügen wir in unserem build.gradle File folgende Dependency hinzu:

testCompile 'io.rest-assured:rest-assured:3.0.5'

Maven User adden folgende Zeilen in ihrem pom.xml:

<dependency>

<groupId>io.rest-assured</groupId>

<artifactId>rest-assured</artifactId>

<version>3.0.0</version>

<scope>test</scope>

</dependency>

Dann noch in der Test Klasse mit import static com.jayway.restassured.RestAssured.*; REST Assured importieren und wir können den ersten Test schreiben.

Ziel des Testfalls ist das Überprüfen von statusCode, id und title im Request Response. Dazu verwenden wir die given / when / then Notation von REST Assured.

@Test

public void T1_getShoppingCart() {

given().

   contentType (“application/json”).

when().

   get(“/getShoppingCart”).

then().

   statusCode(200).

   body("items.id", Matchers.hasItems("54322", "32149")).

   body("items.title", Matchers.hasItems("iPhoneX", "magic mouse"));

Gestartet werden die Tests in Gradle wie gewohnt mit gradle clean test, Maven User verwenden mvn clean test.

Über dieses relativ einfache Beispiel zum Einstieg hinaus, bietet REST Assured natürlich noch viele weitere Möglichkeiten. Hier lohnt sich auf jeden Fall ein Blick in die DOCS.

Wie wir noch nicht implementierte Microservices mocken und das ganze dann in flexible Docker Container verpacken, zeigen wir euch in einem der nächsten Blogposts.

About Sarah

    You May Also Like