Am 17. November geht unsere Tech-Meetup-Reihe WUE.tech in die nächste Runde. Unser Torsten „Totti“ Wunderlich wird euch eine eine Einführung in das Testing mit Postman geben. Doch das ist nur der erste Streich …
… denn in einem Folge-Meetup im Dezember wird er nämlich mit dem Testing aus der Konsole, der Integration von GitHub-Actions und vielem mehr noch tiefer in die Thematik einsteigen.
Doch fangen wir mit dem an, was euch am 17. November erwartet. Dazu haben wir mit Totti gesprochen; u. a. über seine Berührungspunkte mit Postman, über die Herausforderungen des Testens von APIs und über Collections. Aber lest selbst.
Was macht das Testen von APIs so besonders?
Totti: Gar nichts, man muss es halt tun.
Ich finde es ist nicht besonders – es ist sogar einfacher als eine Website zu testen, weil man eine klare API-Definition hat, gegen die man testen kann.
Ein veröffentlichtes API ist ein Vertrag, der das Verhalten klar beschreibt. Es ist anders als ein Unit-Test, aber deswegen noch nicht besonders.
Postman ist vor allem für das Testen von REST-APIs bekannt; was wird darüber hinaus noch abgedeckt?
Totti: Du kannst mit Postman nicht nur APIs testen, sondern auch APIs definieren und Mocks bauen, gegen die man dann entwickeln kann. Das wird aber in meinem Talk nicht abgedeckt, weil wir uns allein auf das Verstehen und Schreiben von Tests mit Postman konzentrieren.
Ein veröffentlichtes API ist ein Vertrag, der das Verhalten klar beschreibt.
Torsten
Postman bietet auch noch die Möglichkeit eines Cloud-Services, sodass man die Tests im Team vernünftig bearbeiten kann, ohne das Ganze importieren und exportieren zu müssen. Das haben wir aber im Projekt nicht benutzt; wir haben Postman als reinen Desktop-Client zum Testen verwendet.
Im nächsten Vortrag im Dezember gehen wir auch noch einmal darauf ein, dass man die Sachen, die man mit Postman zusammenbaut und testet, auch automatisiert auf der Command Line laufen lassen und damit auch in seine Continuous-Integration-Strecke einbinden kann.
Bis zu welcher Komplexität von Tests lässt sich Postman verwenden?
Totti: Bis zu der Komplexität, bei der man sich überlegt „Ich hätte es vielleicht auch direkt als Code schreiben können“.
Es gibt keine praktische Grenze, es gibt nur irgendwann eine gesunde Grenze. Das wird auch Teil des zweiten Vortrags sein.
Es gibt ein paar komische Dinge die man mit Postman anstellen muss, um bestimmte Sachen überhaupt testen zu können. Wir reden über ein paar Schwierigkeiten in die wir reingelaufen sind, bei denen wir uns im Nachhinein schon überlegt haben: „Okay, diesen und jenen Test hätte man einfacher als Go-Test geschrieben“. Vor allem, wenn man in einer Golang-Umgebung ist, die das Testen sehr einfach macht. Da kann man die Tests, die man mit Postman macht (definitiv die kompliziertere) direkt in eine kleine Golang-Testroutine bauen und dann gegen das Produkt schießen.
Wie viel Einarbeitungszeit braucht man, um sich in die JavaScript-Schnittstelle einzuarbeiten … und wieso lohnt sich der Aufwand deiner Meinung nach?
Totti: Die Einarbeitungszeit ist nicht sehr groß. Jemand der in JavaScript firm ist, ist schnell drin.
Wer in JavaScript firm ist, braucht kaum Einarbeitungszeit in die JavaScript-Schnittstelle.
Torsten
Ich habe ein bisschen gebraucht, weil ich die letzten 12 Jahre (aus Gründen) kein JavaScript angeschaut habe. Und selbst ich, der weder Ahnung von JavaScript noch von der Umgebung von Postman hatte, bin da relativ schnell reingekommen.
Die Hürde mit Postman das Testen anzufangen ist erstaunlich gering. Das macht glaube ich auch den Charme aus. Man bekommt relativ schnell genügend gute Ergebnisse, mit denen man weiterarbeiten und feilen kann.
Denn Tests sind letzten Endes ja auch nichts weiter als Code. Ich muss meine Tests genauso pflegen, wie ich mein Produkt und meine APIs pflegen muss. Von daher ist ein Test auch nie wirklich fertig.
Also als Fazit: Der geringe Aufwand lohnt sich definitiv.
Vor allem Collections sind bei Entwickler*innen sehr beliebt. Warum?
Totti: Ich weiß nicht warum sie beliebt sind, aber sie sind notwendig.
Es gibt verschiedene Vokabeln, die man in dem Postman-Umfeld beherrschen muss – und dazu gehören so etwas wie Requests, die die kleinste Einheit darstellen. Daran kleben dann ein paar Tests für diesen einen Request.
Manchmal ist aber ein Workflow jedoch nicht mit einem Request abgedeckt. Da muss zum Beispiel ein Nutzer angelegt werden, dann muss zu diesem Nutzer ein Konto hinzugefügt werden und dann auf das Konto noch Geld überwiesen werden.
Über unser Projekt dedipay habe ich Postman kennen- und lieben gelernt.
Torsten
Um solche Dinge in einer Einheit abdecken zu können, verwendet man Collections. Collections fassen also mehrere atomare Requests zu einer Einheit zusammen. Zum einen werde ich darauf in den Vorträgen eingehen – als auch auf ein paar hilfreiche Techniken, die ich mir dazu angewöhnt habe. Zum anderen werde ich natürlich auch auf Test-Strategien eingehen.
Und wie sieht es mit der Kollaboration mit anderen Entwicklern aus?
Totti: Es gibt einen Online-Cloud-Dienst, der das total einfach macht. Den haben wir aber nicht benutzt. Wir haben unsere Tests geschrieben und sie exportiert.
Da kommt dann nichts anderes als ein JSON raus, in dem die Tests einer Collection beschreiben sind. Diese Collections haben wir einfach im GitHub-Repository abgelegt.
Jeder der damit gearbeitet hat, hat sich diese Collections gezogen und konnte dann weiter testen.
In welchem Kontext bist Du überhaupt mit Postman in Berührung gekommen?
Totti: Durch unser Projekt mit dedipay; das ist ein Zahlungsdienstleister. Mit einer Microservice-Architektur, die in Golang geschrieben ist. Wir haben mitgeholfen diese zu entwickeln und als das für den ersten Nutzer live gehen sollte, haben wir uns gefragt, ob das überhaupt so funktioniert wie es soll.
Freut euch auf einen ehrlichen Erfahrungsbericht aus einem realen Umfeld mit realen Daten.
Torsten
Daraufhin haben wir gemerkt, dass wir nicht nur Unit-Tests, sondern auch End-to-End-Tests brauchen, um einigermaßen auf der sicheren Seite zu sein (Ach!). Wir wollten viele Dinge abprüfen, unter anderem explizit die Außenkante des API.
Als ich auf das Projekt kam, entwickelte ich erst einen Service in Go und schnappte mir dann das Testing. Es gab schon erste Versuche mit Postman; die habe ich übernommen und das ganze Testsystem ausgebaut. Also eine Test-Strategie überlegt, das Ganze strukturiert, dass es auch wiederverwendbar ist, und schön isoliert laufen gelassen werden kann, dass die Datenbank in einem vernünftigen Zustand hinterlassen wird, etc.
Auf was genau dürfen wir uns in Deinem Vortrag freuen?
Totti: Ihr dürft euch auf einen ehrlichen Erfahrungsbericht aus einem laufenden Projekt freuen. Die Betonung auf dem richtigen Projekt deshalb, weil es aus einem realen Umfeld mit realen Daten stammt.
Gleichzeitig biete ich euch auch einen Einblick, wie man eine größere Menge an Tests so strukturiert, dass man den Überblick behält, dass es einfach ist neue Tests hinzuzufügen und man einigermaßen sicher ist, dass man auch viele Fälle abgedeckt hat. Bzw. was man tun kann, um möglichst wenig Fälle zu vergessen.
Also es ist nicht nur ein Vorstellen des Tools, sondern vor allem auch ein „So kann man seine Test-Suite aufbauen, damit man sich nicht ständig in den Fuß schießt“.
Schreibe einen Kommentar