Mariusz ist Experte für Contract-Based Testing. Im Interview sprechen wir darüber, was es mit CBT auf sich hat, wie es leidige Probleme beim Integrationstest löst und wie es generell funktioniert. Mariusz zeigt uns, was es mit Consumer und Producer auf sich hat, welches Framework er benutzt und zählt typische Fallstricke auf, die diese Art zu testen mit sich bringt.
“Die ganzen Interaktionen werden gemockt und eine fertige Implementierung ist an der Stelle nicht nötig” – Mariusz Smoliński
Mariusz ist seit über 12 Jahren in der IT-Branche tätig. Angefangen hat er als IT-Service Desk Mitarbeiter in Support-Projekten für deutsche Kunden im Bankwesen, Industrie und im öffentlichen Sektor. Knapp 4 Jahre später wechselte er zum Testen, und da ist er bis heute geblieben.
In England und Deutschland hat er in verschiedenen Projekten in unterschiedlichen Branchen die Softwarequalität sichergestellt. Am liebsten arbeitet er agil. Privat beschäftigt er sich u.a. mit iOs-Entwicklungen.
Highlights in dieser Episode:
Entdecken Sie die Welt des Contract-Based Testing, eine innovative Methode zur Optimierung der Schnittstellentests in agilen Projekten. Erfahren Sie, wie diese Methode die Zusammenarbeit fördert und die Testprozesse effizienter gestaltet.
In meiner jüngsten Podcast-Episode haben wir uns dem Thema Contract-Based Testing gewidmet – einem Ansatz, der die Testung von Schnittstellen revolutioniert. Dieses Verfahren ist besonders nützlich in der heutigen Zeit, wo Microservices und diverse APIs dominieren. In einem aufschlussreichen Gespräch mit Mariusz Smoliński, einem erfahrenen Anwender von Contract-Based Testing in agilen Projekten, erörterten wir das Konzept, seine Anwendung und dessen zahlreiche Vorteile. Durch diesen Ansatz wird nicht nur die Dokumentation der Schnittstelle stets aktuell gehalten, sondern es fördert auch die Zusammenarbeit zwischen den Teams.
Contract-Based Testing kann als eine Art Vertrag zwischen zwei Parteien verstanden werden: dem Anbieter (Provider) und dem Nutzer (Consumer) einer Schnittstelle. Dabei werden alle Interaktionen präzise definiert. Dieser Prozess hilft dabei, die Kommunikation zwischen Backend und Frontend oder zwischen verschiedenen Services innerhalb einer Organisation zu optimieren. Das Ziel ist es, nur das zu entwickeln und zu testen, was der Consumer wirklich benötigt – ein Prinzip, das auch als „you aren’t gonna need it“ bekannt ist.
Eines der bekanntesten Frameworks zur Unterstützung von Contract-Based Testing ist PACT. Es ermöglicht eine einfache Implementierung und fördert die Zusammenarbeit zwischen den beteiligten Parteien. Die Nutzung eines sogenannten Paktbrokers erlaubt es, dass Verträge leicht zugänglich gemacht werden und immer aktuelle Dokumentation zur Verfügung steht.
Eine interessante Anwendung von Contract-Based Testing ist die Möglichkeit des Mockings bestimmter Schnittstelleninteraktionen. Dies vereinfacht den Testprozess erheblich, da man nicht warten muss, bis die andere Seite ihre Implementierung abgeschlossen hat. Außerdem werden durch diese Methode nur jene Aspekte entwickelt und getestet, die für den Consumer von Bedeutung sind. Dies macht den Entwicklungsprozess effizienter und zielführender.
Trotz seiner vielen Vorteile gibt es Situationen, in denen Contract-Based Testing möglicherweise nicht ideal ist. Zum Beispiel bei öffentlichen APIs oder wenn keine Kontrolle über sich ändernde Daten besteht. Auch politische Entscheidungen innerhalb eines Projekts können die Implementierung dieser Testmethode beeinflussen.
Die Einführung von Contract-Based Testing bietet viele Vorteile: es spart Zeit, fördert klare Kommunikation zwischen den Teams und sorgt für aktuelle Dokumentation. Allerdings ist es wichtig zu wissen, wann diese Methode angebracht ist und wann andere Werkzeuge besser geeignet wären. Mariusz teilte wertvolle Einblicke aus seiner praktischen Erfahrung, was diese Episode zu einer wahren Fundgrube an Informationen machte.