Manchmal muss an einem System etwas Grundlegendes umgebaut werden, und trotzdem soll sich für die Nutzer nichts ändern. Die bestehende Funktionalität bleibt erhalten, die Technik darunter wird neu. Woher weiss man am Ende, dass wirklich alles noch stimmt?
In solchen Situationen setzen wir Golden-Master-Testing ein.
Ein Golden-Master-Test beschreibt nicht das Soll, sondern das Ist: Wie hat sich der Code vor dem Umbau verhalten.
Nicht nur für Legacy-Ablösungen
Am bekanntesten ist die Methode aus der Legacy-Ablösung, wenn eine in die Jahre gekommene Software-Lösung durch eine moderne ersetzt wird, sich das Verhalten aber nicht ändern soll. Dort ist Golden-Master-Testing ein wichtiger Baustein, wie wir in einem früheren Blog-Post beschrieben haben.
Der Ansatz lässt sich aber genauso gut auf grosse Umbauten an einem bestehenden und aktiv weiterentwickelten System anwenden. Das kann der Austausch einer zentralen Library sein, die Konsolidierung eines Technologie-Stacks oder ein Service, der hinter einer stabilen Schnittstelle komplett neu gebaut wird. In allen Fällen dient der alte Stand als Referenz, an der sich der neue Stand messen lässt.
Eine Spezifikation braucht es nicht
Ein Golden-Master-Test beschreibt nicht das Soll, sondern das Ist: Wie hat sich der Code vor dem Umbau verhalten. Er nimmt dafür das Verhalten des alten Stands als Referenz. Eine vollständige Spezifikation ist dafür nicht nötig, denn das bestehende Verhalten selbst ist die Spezifikation.
Diese Tests sind unser Sicherheitsnetz. Grün heisst, das Verhalten ist gleich geblieben. Rot heisst, hier hat sich etwas verändert. Ein roter Test ist deshalb kein Ärgernis, sondern das Signal, das wir suchen. Er zeigt genau die Stelle, an der der neue Stand vom alten abweicht.
Jeder rote Test verlangt dann eine Entscheidung. Ist es ein Fehler, korrigieren wir den Code, und der Test wird wieder grün. Ist die Änderung allerdings erwünscht, übernehmen wir das neue Verhalten in den Test. So bleibt keine Abweichung unbemerkt.
Auch undokumentiertes Verhalten erfassen
Breite End-to-End-Tests halten fest, welche Antwort das System auf eine Anfrage gibt. Feinere Service- und Unit-Tests sichern das Verhalten im Innern.
Die eigentliche Arbeit steckt darin, dieses Verhalten genau zu erfassen, auch die Teile, die nie jemand dokumentiert hat. Genau dabei hat sich ein LLM in unserer Arbeit bewährt. Es geht das alte System durch, arbeitet sein tatsächliches Verhalten heraus und erzeugt daraus die Tests samt dem erwarteten Ergebnis, gegen das später geprüft wird.
Die Struktur geben wir vor, und jeden erzeugten Test prüfen wir manuell. Die Tests sind die Referenz für den ganzen Umbau, ein falscher Test würde ein falsches Verhalten für immer festschreiben.
Ein grosser Umbau unter Kontrolle
Wir haben diesen Golden-Master-Ansatz bei einem grossen Refactoring des Organisation-Service in Uniport eingesetzt.
Der Organisation-Service erweitert das quelloffene Keycloak um die Funktionen, die B2B-Portale beim Benutzer- und Zugriffsmanagement brauchen. Dazu gehören die Trennung mehrerer Mandanten und eine delegierte Benutzerverwaltung, bei der jede Organisation ihre eigenen Benutzer selbst pflegt.
Mehr zu unserem B2B-IAM auf der Produktseite von Uniport IAM.
Zwei zentrale Bereiche haben wir komplett umgeschrieben. Für den Datenbankzugriff haben wir die Library von JPA auf JOOQ ersetzt. Die Berechtigungen prüfte früher ein eigenständiger Service, der Open Policy Agent. Heute schützt unser in JOOQ integriertes Regelwerk-Framework jede Datenbankabfrage direkt. Durch diesen Umbau konnten wir die Komplexität reduzieren. Früher liefen vier Services, heute genügt einer. Das vereinfacht die Wartung und den Betrieb.
Ein so tiefer Eingriff kann an vielen Stellen unbemerkt das Verhalten verändern. Genau diese Stellen machten die Golden-Master-Tests sichtbar. Jeder Unterschied zwischen dem alten und dem neuen Stand wurde zu einem roten Test. So blieb der Umbau kontrollierbar, und wir sahen jederzeit, wo es noch hakte. Und am Ende waren wir sicher, dass das neue System genauso funktioniert wie das alte.
Gewissheit statt Hoffnung
Ein grosser Umbau muss kein Blindflug sein. Ist das alte Verhalten erst in Tests festgehalten, wird jede Abweichung sichtbar, und aus einem vagen Risiko wird eine Reihe bewusster Entscheidungen. Wir tauschen uns gerne darüber aus, wo sich dieser Aufwand lohnt und wo nicht.
