© Liashko/Shutterstock.com
Entwickler Magazin
API-Testautomatisierung auf einfache Art und Weise?

Test-Framework Karate

Sobald man APIs entwickelt, steht man vor dem Problem, wie man sie testet. Mit Karate [1] gibt es ein Framework, das auf Basis von Cucumber [2] eine einfache Möglichkeit bietet, den Test in die Softwareentwicklung zu integrieren.

Alexander Frommelt


In der heutigen Zeit, in der Microservices die Entwicklung bestimmen, startet fast jedes Projekt entweder mit der Definition oder Nutzung von APIs. Doch wie können sie sinnvoll getestet werden? Auf dem Markt haben sich dafür Postman [3] oder SoapUI [4] als Quasistandards durchgesetzt, die neben dem Test der API-Schnittstellen auch die Entwicklung und Definition beispielsweise durch Designwerkzeuge und Mocks mit mächtigen Oberflächen unterstützen. Auf der anderen Seite stellt sich immer wieder heraus, dass diese Tools nur schwer in einem Team einzusetzen sind, um gemeinsam an APIs und deren Tests zu arbeiten, insbesondere wenn man nicht die kommerzielle Enterprise-Variante der Tools einsetzen möchte.

Beide Tools erzeugen zur Ablage des API und der Testfallbeschreibungen große Datenfiles auf JSON- oder XML-Basis. Will man diese, wie allen anderen zur Anwendung gehörenden Code, in seiner Source-Verwaltung pflegen, wird man bemerken, dass das nicht einfach ist. Plötzlich ist ein Testfall verschwunden oder lässt sich nicht mehr ausführen, da ein Kollege eine neue Version gespeichert hat. Aufgrund der komplexen Datenmodelle, in denen sowohl SoapUI als auch Postman ihre Daten ablegen, ist es schwierig, beim Merge den Überblick zu behalten und keine Inkonsistenzen zu erzeugen. Die Testfälle müssen jedoch während der Entwicklung kontinuierlich gepflegt und weiterentwickelt werden, da zum Beispiel neue Testfälle für neue Features dazukommen, Fehler in Testfällen bereinigt werden müssen oder das API an sich weiterentwickelt wird. Die landläufige Meinung, dass APIs etwas Statisches sind und damit keiner oder nur geringer Veränderung unterliegen, ist leider falsch. Selbst kleine Änderungen an der implementierenden Anwendung, beispielsweise an Validierungsregeln, können schon eine Änderung im Verhalten des API verursachen. Um das frühzeitig zu erkennen und gegebenenfalls Maßnahmen ergreifen zu können, ist es sinnvoll, das API sowohl für den Consumer als auch für den Producer kontinuierlich automatisiert zu testen.

Viel einfacher wäre es doch, eine simple Beschreibung der Testfälle in Form von Textfiles zu haben, quasi API-Testautomatisierung-as-Code. Diese Beschreibung wäre auch problemlos über die Source-Code-Verwaltung zu pflegen. Ein weiterer Vorteil davon wäre, dass die Testfälle immer dem aktuellen Source-Stand entsprechen und über Branching und Tagging jederzeit wieder konsistent zum Source-Stand reproduziert werden können.

Das Open Source Framework Karate der Fi...

Entwickler Magazin
API-Testautomatisierung auf einfache Art und Weise?

Test-Framework Karate

Sobald man APIs entwickelt, steht man vor dem Problem, wie man sie testet. Mit Karate [1] gibt es ein Framework, das auf Basis von Cucumber [2] eine einfache Möglichkeit bietet, den Test in die Softwareentwicklung zu integrieren.

Alexander Frommelt


In der heutigen Zeit, in der Microservices die Entwicklung bestimmen, startet fast jedes Projekt entweder mit der Definition oder Nutzung von APIs. Doch wie können sie sinnvoll getestet werden? Auf dem Markt haben sich dafür Postman [3] oder SoapUI [4] als Quasistandards durchgesetzt, die neben dem Test der API-Schnittstellen auch die Entwicklung und Definition beispielsweise durch Designwerkzeuge und Mocks mit mächtigen Oberflächen unterstützen. Auf der anderen Seite stellt sich immer wieder heraus, dass diese Tools nur schwer in einem Team einzusetzen sind, um gemeinsam an APIs und deren Tests zu arbeiten, insbesondere wenn man nicht die kommerzielle Enterprise-Variante der Tools einsetzen möchte.

Beide Tools erzeugen zur Ablage des API und der Testfallbeschreibungen große Datenfiles auf JSON- oder XML-Basis. Will man diese, wie allen anderen zur Anwendung gehörenden Code, in seiner Source-Verwaltung pflegen, wird man bemerken, dass das nicht einfach ist. Plötzlich ist ein Testfall verschwunden oder lässt sich nicht mehr ausführen, da ein Kollege eine neue Version gespeichert hat. Aufgrund der komplexen Datenmodelle, in denen sowohl SoapUI als auch Postman ihre Daten ablegen, ist es schwierig, beim Merge den Überblick zu behalten und keine Inkonsistenzen zu erzeugen. Die Testfälle müssen jedoch während der Entwicklung kontinuierlich gepflegt und weiterentwickelt werden, da zum Beispiel neue Testfälle für neue Features dazukommen, Fehler in Testfällen bereinigt werden müssen oder das API an sich weiterentwickelt wird. Die landläufige Meinung, dass APIs etwas Statisches sind und damit keiner oder nur geringer Veränderung unterliegen, ist leider falsch. Selbst kleine Änderungen an der implementierenden Anwendung, beispielsweise an Validierungsregeln, können schon eine Änderung im Verhalten des API verursachen. Um das frühzeitig zu erkennen und gegebenenfalls Maßnahmen ergreifen zu können, ist es sinnvoll, das API sowohl für den Consumer als auch für den Producer kontinuierlich automatisiert zu testen.

Viel einfacher wäre es doch, eine simple Beschreibung der Testfälle in Form von Textfiles zu haben, quasi API-Testautomatisierung-as-Code. Diese Beschreibung wäre auch problemlos über die Source-Code-Verwaltung zu pflegen. Ein weiterer Vorteil davon wäre, dass die Testfälle immer dem aktuellen Source-Stand entsprechen und über Branching und Tagging jederzeit wieder konsistent zum Source-Stand reproduziert werden können.

Das Open Source Framework Karate der Fi...

Neugierig geworden?


    
Loading...

Angebote für Teams

Für Firmen haben wir individuelle Teamlizenzen. Wir erstellen Ihnen gerne ein passendes Angebot.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang