Hallo Spa\u00df-Coder.<\/p>\n
Bei unseren Artikeln zum Thema Testautomatisierung<\/a> haben wir immer mal wieder darauf hingewiesen, dass wir keine Abh\u00e4ngigkeiten zur Peripherie haben m\u00f6chten, um m\u00f6glichst ungest\u00f6rt und schnell testen zu k\u00f6nnen. Wer hat sich bei diesen Artikeln nicht schon einmal die Frage gestellt, was das denn in der Praxis bedeutet?<\/p>\n Heute m\u00f6chten wir uns an einem ganz konkreten Beispiel einmal anschauen, wie das nun funktioniert mit dem Abtrennen der Abh\u00e4ngigkeiten f\u00fcr den Test.<\/p>\n <\/p>\n Das Konzept der RESTful Services teilt sich in zwei Teile auf.<\/p>\n Auf der einen Seite haben wir den Server<\/strong>, der REST-Anfragen entgegen nimmt, verarbeitet und ein Ergebnis zur\u00fcckliefert. Die Kommunikation erfolgt via HTTP, das Austauschformat ist frei w\u00e4hlbar, hier hat sich allerdings f\u00fcr die meisten Services JSON als Format etabliert, wenn es um den Austausch von Daten geht.<\/p>\n Auf der anderen Seite steht der Client<\/strong>, der die REST-Anfrage via HTTP\u00a0 stellt, das Ergebnis vom REST-Server bekommt und weiterverarbeitet.<\/p>\n Zwischen diesen beiden beteiligten findet eine Kommunikation statt. Der eine kann ohne den anderen nicht funktionieren, es wird immer eine Gegenstelle ben\u00f6tigt, um die Verarbeitung vollst\u00e4ndig abzuschlie\u00dfen. Genau dies f\u00fchrt zu dem Problem, dass wir die beiden Teile des REST-Services nicht gut testen k\u00f6nnen.<\/p>\n Was aber k\u00f6nnen wir tun? Zun\u00e4chst sichern wir alle Einzelteile auf der jeweiligen Seite die wir implementieren mit Unit-Tests ab. Das machen wir immer, also auf jeden Fall auch hier. Je fr\u00fcher wir in der Kette einen Fehler finden – und die Unit ist die Kleinste Einheit, die einen Fehler haben kann – desto leichter f\u00e4llt die Analyse, die Behebung und das Sicherstellen, dass der Fehler nicht wieder auftritt.<\/p>\n <\/p>\n Wir haben also unseren RESTful-Client geschrieben und die interne Verarbeitungen mit Unit-Tests abgesichert. Nun m\u00f6chten wir aber auch die Methoden, welche die REST-Daten ben\u00f6tigen automatisiert testen. Wie machen wir das?<\/p>\n <\/p>\n Auf dieses Konzept sind wir in der Vergangenheit bereits eingegangen. Wir nutzen ein Mocking-Framework um die externen Abh\u00e4ngigkeiten zu verstecken. Wir nutzen in solchen F\u00e4llen f\u00fcr unseren Java-Code das Framework Mockito<\/a>, ein aktives Open-Source-Projekt, welches sehr m\u00e4chtig und gut dokumentiert ist.<\/p>\n Nehmen wir als Beispiel eine Kochbuch-Anwendung. Hierbei werden Rezepte (Recipes) und Zutaten (Ingredients) verwaltet. Wir wollen das Repository, welches die Rezepte vom Server abfragt testen, ohne dass die tats\u00e4chliche Abfrage zum Server durchgef\u00fchrt wird.<\/p>\n <\/p>\n Wie wir sehen hilft es uns hier, dass wir mit Constructor-based Injection arbeiten. Auf diese Weise k\u00f6nnen wir dem REST-Client im Konstruktor die erstellten Mock-Objekte \u00fcbergeben und diesen damit vom Server abschneiden. Wir k\u00f6nnen also in Frieden unseren Test durchf\u00fchren.<\/p>\n Durch das Mocken der Objekte befinden wir uns weiterhin auf der Ebene des Unit-Tests, da wir die integrierten Abh\u00e4ngigkeiten durch Mock-Objekte ersetzt haben.<\/p>\n <\/p>\n Wollen wir nun aber tats\u00e4chlich mal schauen, wie sich der REST-Client denn in einer „echten Welt“ verh\u00e4lt, m\u00fcssen wir einen Integrationstest schreiben. Wir brauchen dazu auf jeden Fall einen REST-Server, der unsere REST-Anfrage beantwortet.<\/p>\n Vielleicht stellt ihr euch die Frage, warum wir denn nicht gleich gegen den echten Server testen. Nun, das k\u00f6nnen wir in dem Beispiel nat\u00fcrlich gefahrlos tun, hier werden ja nur GET-Anfragen aufgerufen, also Daten abgefragt.<\/p>\n Aber steht uns der Server \u00fcberhaupt zur Verf\u00fcgung? Wenn wir ein Fremdes System anbinden, ist das ggf. gar nicht der Fall. Daf\u00fcr m\u00fcssen wir unter Umst\u00e4nden sehr viel Aufwand betreiben um die Infrastruktur entsprechend einzurichten.<\/p>\n Auf der Anderen Seite wollen wir ja auch alle Facetten des REST-Clients testen. Wie sieht es z.B. aus, wenn wir keinen GET, sondern einen PUT machen, also Daten ver\u00e4ndern. Oder gar ein DELETE, also Daten l\u00f6schen. Das m\u00f6chten wir sicher nicht auf einem Produktivsystem machen.<\/p>\n Den Stub-Server k\u00f6nnen wir f\u00fcr alle Aufrufe so gestalten, dass er genau die Daten zur\u00fcckgibt, die wir erwarten, ohne teure Anbindung an weitere Infrastrukturen. Auf diesem Weg k\u00f6nnen wir auch das Fehlerverhalten testen, indem wir einfach mal „M\u00fcll“ oder Fehlercodes – wie etwa keine Berechtigung oder einen internen Serverfehler – zur\u00fcckgeben.<\/p>\n <\/p>\n Auf Seiten des REST-Servers haben wir eine ganz andere Herausforderung. In aller Regel haben wir eine Webanwendung mit einem Controller und einem RequestMapping. Wie aber testen wir dies? Das Mapping, den Controller, die R\u00fcckgabe, das Fehlerverhalten?<\/p>\n Hinweis:<\/strong> Dieses Verfahren funktioniert nur dann, wenn wir unseren Controller mit dem Framework Spring Web MVC <\/a>implementiert haben, da die eingesetzte Mocking-Bibliothek ebenfalls aus dem Springframework stammt (Spring Test<\/a>).<\/p>\n Auch hier testen wir zun\u00e4chst die kleinsten Einheiten mit Hilfe von Unit Tests. F\u00fcr die request-basierten Tests nutzen wir wiederum die M\u00f6glichkeit des Mockings. Spring Test bietet uns hier die M\u00f6glichkeit komfortabel einen Controller \u00fcber einen gefakten Request aufzurufen und das Ergebnis zu pr\u00fcfen.<\/p>\n Wie wir sehen k\u00f6nnen wir nach dem Setup des Controllers mit Hilfe des Test-Frameworks von Spring diesen sch\u00f6n einfach aufrufen und somit auf Herz und Nieren Testen.<\/p>\n Dies ist nat\u00fcrlich einer der einfachsten Tests. Spannend wird es auch hier insbesondere dann, wenn wir Fehlerverhalten, falsche Parameter, etc. testen.<\/p>\n <\/p>\n Wie so oft kommt es auch beim Test von RESTful Services darauf an, die Stellen zu erkennen, die uns den Test erschweren und diese m\u00f6glichst abzukapseln.<\/p>\n Wichtig ist noch der Hinweis, dass wir beim Test immer darauf achten m\u00fcssen, nicht das wegzumocken, was wir eigentlich testen m\u00f6chten. Das ist leichter gesagt, als es sich in der Realit\u00e4t darstellt. Ist am Anfang noch klar, was getestet werden soll, verrennt man sich ggf. schnell in Mock-Objekten, insbesondere bei Legacy-Code.<\/p>\n Bei neuen REST-Clients oder REST-Services sollte dieses Problem nicht so schnell auftreten, Vorsicht ist trotzdem geboten. Aber die lassen wir ja ohnehin immer walten bei unserem Code, wir sind schlie\u00dflich Profis \ud83d\ude09<\/p>\n <\/p>\n In diesem Sinne, viel Spa\u00df beim Testen der RESTs dieser Welt \ud83d\ude09<\/p>\n Eure Spa\u00df-Coder<\/p>\n <\/p>\n Dieser Artikel basiert neben unseren Erfahrungen auf den Ausf\u00fchrungen aus:<\/p>\nDevided REST-Rooms<\/h1>\n
REST in Peace – Client<\/h1>\n
Mocking<\/h2>\n
@Test\r\npublic void testFindRecipesByIngredientName() throws Exception {\r\n\tJsonConfiguration jsonConfiguration = mock(jsonConfiguration.class)\r\n RestService restService = mock(RestService.class);\r\n\r\n Recipe[] expected = new Recipe[1];\r\n Recipe recipe = new Recipe();\r\n recipe.setId(\"38\");\r\n recipe.setName(\"Spaghetti Bolognese\");\r\n\texpected[0] = recipe;\r\n\r\n when(jsonConfiguration.getUrl()).thenReturn(\"\");\r\n when(restService.findObject(anyString(), anyString(), any())).thenReturn(expected);\r\n \r\n\tRecipeRestRepository sut =\r\n new RecipeRepository(jsonConfiguration, restService);\r\n\tRecipe[] actual = sut.ReadByIngredientName(\"Spaghetti\");\r\n \r\n\tAssertions.assertThat(actual[0].getId()).isEqualTo(\"38\");\r\n Assertions.assertThat(actual[0].getName()).isEqualTo(\"Spaghetti Bolognese\");\r\n}<\/pre>\nStub-Server<\/h2>\n
[configuration.server=http:\/\/testserver:8082]\r\n\r\n@Override\r\npublic Recipe[] findByIngredient(String ingredientName) {\r\n\tfinal String url = jsonConfiguration.getUrl() + \"\/findByIngredient\/\" + ingredientName;\r\n\treturn restService.findObject(url, \"Error finding recipe.\", Recipe[].class);\r\n}<\/pre>\nControl the REST – Server<\/h1>\n
@Test\r\npublic void testGetRecipeByIngredientRespondsWithJson() throws Exception {\r\n\tRecipeRepository recipeRepository = mock(RecipeRepository.class);\r\n\r\n\tString recipeId = \"38\";\r\n\tString recipeName = \"Spaghetti Bolognese\";\r\n\r\n\tRecipe recipe = new Recipe();\r\n recipe.setId(recipeId);\r\n recipe.setName(recipeName);\r\n\t\r\n\twhen(recipeRepository.findByIngredient(ingredientName))\r\n\t\t\t.thenReturn(recipe);\r\n\r\n\tfinal MockMvc mockMvc = standaloneSetup(new RecipeController(recipeRepository))\r\n\t\t\t.build();\r\n\r\n\tmockMvc.perform(get(\"\/recipes\/findByIngredientName\/\" + \"Spaghetti\"))\r\n\t\t\t.andExpect(status().isOk())\r\n\t\t\t.andExpect(\r\n\t\t\t\t\tcontent().contentType(MediaType.APPLICATION_JSON_VALUE))\r\n\t\t\t.andExpect(jsonPath(\"$.recipeId\").value(recipeId))\r\n\t\t\t.andExpect(jsonPath(\"$.recipeName\").value(recipeName));\r\n}<\/pre>\nZusammenfassung<\/h1>\n