Testen in der modularisierten Welt

TeamworkAm 25. März 2015 hatte das Quality Engineering Team von ImmobilenScout24 (IS24) zum 2. QE Stammtisch mit dem Titel „Testen von verteilten Applikationen“ geladen. Kernfrage war: „Wie testen wir das Zusammenspiel unabhängig voneinander deployter Systeme?“ Wenn jedes agile Team sein eigenes Modul testet, wer stellt sicher, dass alles zusammen funktioniert? Zusammen mit Entwicklern und Testern verschiedener Portalbetreiber, darunter weitere Größen wie idealo und Zalando, wurde in lockerer Atmosphäre diskutiert. Norbert Kroth, Solution Consultant Web Portal Solutions und ich haben brightONE vertreten.

Lesen Sie weiter, wie sich klassische Module von microservices unterscheiden und warum der Integrationstest weiterhin ein heißes Thema bleibt.

Microservices vs. klassische Module

Um ein gemeinsames Verständnis von Modulen zu gewinnen, wurde zunächst definiert, was ein Modul ist. Nehmen wir (naheliegend) an, unsere Applikation enthält Funktionen für Makler, Baufinanzierer und potentielle Käufer; nehmen wir ferner an, das Softwaredesign sieht eine Trennung in GUI, Geschäftslogik und Datenbank vor. Als klassisches Modul würde man z.B. die Geschäftslogik für alle Anwendergruppen wählen, mit dem Vorteil GUI und Datenbank mit marginalem Aufwand austauschen zu können. Bezeichnet als „horizontaler“ Schnitt.

Microservices würde man „vertikal“ zuschneiden. In unserem Beispiel würde für jede Anwendergruppe, sprich jedes Feature, ein Microservice entwickelt werden, welche sich autark um alle Anwendungsschichten kümmern; wobei anzumerken ist, dass „echte“ GUI Entwicklung aufgrund der allgemeinen Verfügbarkeit entsprechender Toolkits in den Hintergrund getreten ist. Microservices decken nach der reinen Lehre nur ein Feature ab, werden von einem Team entwickelt und verwenden die vom Team favorisierten Technologien! Hauptaugenmerk liegt nun auf der Kommunikation der zahlreichen Microservices untereinander. Für IS24 sind Microservices z.B. single sign-on, search, agent- und customer insertion. Mehr über Microservices als Softwaredesign Paradigma findet man hier.

Klassischer Integrationstest, nein danke?

Diskussionsthemen waren im Vorfeld nicht vorgegeben. Auf Nachfrage und nach Abstimmung hat man sich auf die vier Themengebiete Sicherstellung der Schnittstellenkompatibilität (meine Gruppe), Dependency-Management, geeignete Testumgebungen und 3rd Party Tests geeinigt, die dann in einzelnen Gruppen behandelt wurden. Nach 20 Minuten angeregter Diskussion wurden die Ergebnisse dann der Allgemeinheit vorgestellt.

Wie stellt man Schnittstellenkompatibilität sicher? Allgemeiner Konsens bestand darin, das klassische Ende-zu-Ende Tests nicht die Lösung darstellen. Werden diese doch als zu teuer, langwierig und unzuverlässig (Stichwort: flaky tests [1][2]) wahrgenommen. Klassische Integrationsteststrategien (top-down, bottom-up, backbone), wie sie in [Spillner05] beschrieben sind kamen nicht zur Sprache. Anmerkung: Sind diese in Vergessenheit geraten, oder auf dem Altar der Agilität geopfert worden? Meines Erachtens haben sie in der Welt der Microservices mehr Daseinsberechtigung als je zuvor. Die Möglichkeit des „mockings“ wurde erwähnt, aber aufgrund des Anpassungsbedarfes an neue Schnittstellenversionen verworfen.

Von Verträgen und Vertrauen

Eine sehr interessante Teststrategie trägt den Namen „consumer-driven contracts[1][2]. Hierbei schreibt der consumer die Integrationstests, welche seine Erwartungen an die Schnittstelle zum Ausdruck bringen. Diese Tests werden dem provider übergeben, welcher sie dann in seiner Testsuite ausführt. Diese Vorgehensweise ist zudem einfach in ein bestehendes continuous integration Konzept einzubinden.

Weit verbreitet ist auch „Vertrauen“ als Integrationsteststrategie. Hier: Vertrauen in den Modultest, begründet durch die agilen Methoden und deren inhärente Fixierung auf technische Exzellenz. Zumindest bei nicht kritischen Modulen kommen hier auch extrem schnelle Release-Zyklen zu Hilfe, die etwaige Fehler quasi unsichtbar werden lassen. Anmerkung: Aber ist Kontrolle nicht doch besser? Betrachtet man den Test von 3rd Party Modulen, ein verwandtes Thema, welches in einer der Nachbargruppen zu Sprache kam, dann ist Vertrauen, nach einer Kosten-Nutzen-Analyse durchaus eine geeignete Strategie. Um nicht blind vertrauen zu müssen, kann man versuchen über Fehlerstatistiken und weitere Metriken die Qualität dieser Module beurteilen.

IS24 nutzt erfolgreich unsere Agile@brightONE Lösung für eine flexible Portalentwicklung. Laden Sie sich hier die Kundenreferenz herunter.

Nie wieder einen Blogartikel verpassen >>> Zum Blog-Newsletter anmelden

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

1 × 4 =