Microservice-Architekturen testen
Microservices bieten zahlreiche Vorteile. Die Komplexität des Testens nimmt allerdings deutlich zu. Ein Codebeispiel zeigt, wie man damit umgeht.
- Sven Hettwer
Bei Microservice-Architekturen verteilt sich die Fachlichkeit über mehrere Komponenten. Anforderungen, die zuvor in unterschiedlichen Modulen desselben Systems realisiert wurden, sind nun in Services aufgeteilt, die durch Schnittstellen, Kommunikationsprotokolle und Netzwerke entkoppelt sind. Tests, die sicherstellen, dass eine komplexe Fachlichkeit korrekt implementiert ist, müssen ganze Abschnitte der Architektur betrachten. Dazu kommt, dass jeder Service seine eigene Fachlichkeit mitbringt, die ebenfalls korrekt zu implementieren und aussagekräftig zu testen ist.
Es genügt nicht mehr, Mocks anderer Module zu verwenden, um das reibungslose Zusammenspiel zu gewährleisten. Stattdessen sind die Schnittstellen der angrenzenden Systeme zu simulieren und auf korrekte Ansteuerung zu prüfen. Testdatensätze setzen sich beispielsweise aus JSON- oder XML-Grundgerüsten mit variablen Werten zusammen. Daraus ergibt sich, dass Microservices als Pattern die Anzahl der Schnittstellenintegrationen über Kommunikationstechnologien innerhalb des Gesamtsystems im Vergleich zum Monolithen stark erhöhen. Diese veränderten Grundvoraussetzungen erfordern andere Herangehensweisen bei der technischen Umsetzung, den Werkzeugen und der Methodik im Zusammenhang mit Testing. Bekannte Probleme bleiben allerdings bestehen.
Unit-Tests alleine reichen nicht mehr aus
Je verteilter Systeme werden, desto klarer wird, dass Unit-Tests alleine nicht mehr ausreichen. Komponenten-, Integrations- und End-to-End-Tests waren schon immer empfehlenswert. Durch Microservices ist ihre Bedeutung deutlich gestiegen. Integrationstests, die fachliche Zusammenhänge isoliert für einen Service oder serviceübergreifend testen, werden in modernen Systemarchitekturen zur Grundlage der Sicherung von funktionaler Korrektheit. Die Probleme dabei haben sich nicht verändert. Dazu gehören der Austausch von Anforderungen zwischen der Fachabteilung und den Entwicklungsteams, die Sicherstellung einer aussagekräftigen Testabdeckung sowie das Einhalten gängiger Clean-Code-Prinzipien. Methoden wie Test-driven Development (TDD) und Behavior-driven Development (BDD) decken diese Anforderungen bei richtiger Anwendung nahtlos ab.
Das war die Leseprobe unseres heise-Plus-Artikels "Microservice-Architekturen testen". Mit einem heise-Plus-Abo können Sie den ganzen Artikel lesen.
