Microservices sind lose miteinander gekoppelt und können beliebig untereinander kommunizieren. Die Schnittstelle wird typischerweise mittels REST im Web bzw. MQTT im embedded Umfeld realisiert. Vereinfacht gesagt entsprechen Microservices dem Single Responsibility Principle (SRP), das man aus der objektorientierten Welt kennt, nur eben auf der fachlichen Ebene.
Vorteil ist, dass Microservices einfach ausgetauscht werden können, solange die Schnittstelle nach außen hin gleich bleibt. Die Eigenverantwortlichkeit eines Teams wird insofern untermauert, dass es innerhalb eines Microservices typischerweise keine technologischen Vorgaben gibt und das Team selbst über den Release-Zeitpunkt entscheidet.
Diese Fakten stellen das Testen vor neue Herausforderungen:
- Es gibt kein statisches System mehr.
- Ursache und Wirkung oft schwierig gegenüber zu stellen.
- "Jeder" kann ein Microservice verwenden.
- Es gibt keinen mehr, der vollständig das System versteht.
- Rückwärtskompatibilität von Microservices gewährleisten.
Somit bekommt die Testpyramide einen noch wichtigeren Stellenwert zugesprochen. Das Team muss dafür Sorge tragen, ihr Microservice mit bestmöglicher Qualität auszuliefern, d.h. ein hoher Überdeckungsgrad von Unit- und Integrationstests ist essentiell.
Auf höherer Ebene betrachtet ist eine herkömmliche REST-Schnittstellenbeschreibung unzureichend. Hier gibt es auf Tool-Seite Abhilfe, wie z.B. RAML. Um jedoch auf der sicheren Seite zu sein, empfiehlt sich Consumer Contract-Driven Testing. Der Konsument liefert Tests, wie er das Microservice verwendet. Der Produzent wird frühzeitig von diesen Tests auf einen Vertragsbruch hingewiesen.
Schlussendlich kann man präventiv viel Testen, aber verteilte Systeme haben das inhärente Problem, dass sie prinzipiell unter einer schlechten Verfügbarkeit leiden, insofern keine Redundanzen vorgesehen sind. Hardwarefehler, wie z.B. defekte Festplatten sind Faktum, man muss mit ihnen leben. Somit ist als zusätzliche Absicherung ein Monitoring empfehlenswert, um rechtzeitig auf Anomalien bzw. nicht-verfügbare Microservices reagieren zu können.
Einen neuen Ansatz in diesem Kontext hat Netflix geprägt, nämlich das Testen in Produktion. Die Idee ist, beliebige Microservices außer Betrieb zu setzen und zu testen, ob das Gesamtsystem nach wie vor den Betrieb aufrecht erhalten kann. Weitere Tests in Produktion sind z.B. künstlich Latenzen einzupflanzen bzw. Microservices auf Schnittstellenkonformität zu prüfen.
Microservices sind ein spannender Architekturstil, um komplexe Systeme zu realisieren, die mit einer monolithischen Herangehensweise nicht mehr durchführbar wären. Die Komplexität erhöht sich dadurch im Test, aber mit einer geeigneten Teststrategie lässt sich auch das Testen in den Griff bekommen.
Wenn Sie an weiteren Methoden und praktischen Ansätzen interessiert sind, besuchen Sie dazu unser neues Training zu diesem Thema. Unter https://www.software-quality-lab.com/leistungen/seminare-trainings/thema/Testen-von-Microservices/ finden Sie weitere Informationen.