Erst das Sicherheitsnetz: Wie KI Charakterisierungstests für Legacy-Code ohne Tests erzeugt

Das Wichtigste in Kürze Das größte Hindernis bei der Modernisierung von Legacy-Software ist selten die Technologie selbst. Es ist die Angst: Niemand weiß genau, was das System tut, es gibt keine Tests, die das bestätigen, und jede Änderung birgt das Risiko, etwas zu beschädigen, auf das Kunden angewiesen sind. Charakterisierungstests lösen dieses Problem, indem sie festhalten, wie sich der Code heute verhält, bevor jemand ihn verändert. Sie von Hand zu schreiben war schon immer langwierig und mühsam, weshalb viele Teams darauf verzichtet haben. KI verändert diese Rechnung. Richtig eingesetzt, analysiert sie unbekannten Code, schlägt Testfälle vor und erzeugt einen Großteil des Testgerüsts in Tagen statt Monaten. Unsachgemäß eingesetzt, produziert sie Tests, die überzeugend aussehen, aber nichts absichern. Dieser Beitrag zeigt, wie KI-generierte Charakterisierungstests funktionieren, wo sie echten Mehrwert bieten, wo ihre Grenzen liegen und wie Sie ein Sicherheitsnetz aufbauen, dem Sie tatsächlich vertrauen können.

Warum Legacy-Code ohne Tests so schwer zu ändern ist

Die meisten Unternehmen haben mindestens ein System, das niemand gern anfasst. Es funktioniert, es verdient Geld, und es ist über zehn oder fünfzehn Jahre durch die Hände von Entwicklern gewachsen, die längst nicht mehr im Unternehmen sind. Gerade im deutschen und österreichischen Mittelstand sind solche Systeme oft das Rückgrat des Geschäfts. Das Problem ist nicht, dass der Code alt ist, sondern dass sein Verhalten weder dokumentiert noch überprüft ist.

Ohne automatisierte Tests wird jede Änderung zum Glücksspiel:

• Entwickler können nicht erkennen, ob eine Anpassung einen Sonderfall beschädigt, an den sich niemand mehr erinnert,
• manuelle Regressionstests wachsen mit jedem Release und übersehen trotzdem Fehler,
• Refactoring wird immer wieder verschoben, weil das Risiko größer erscheint als der Nutzen,
• Wissen bleibt in den Köpfen weniger erfahrener Personen, die zum Engpass werden.

Das Ergebnis ist ein Teufelskreis. Code ohne Tests ist riskant zu ändern, also verbessert ihn niemand, also wird er noch schwerer zu ändern. Um diesen Kreis zu durchbrechen, braucht es ein Sicherheitsnetz, bevor strukturelle Arbeiten beginnen.

Was Charakterisierungstests sind und warum sie am Anfang stehen

Bekannt gemacht hat den Begriff Michael Feathers in seinem Buch Working Effectively with Legacy Code. Ein Charakterisierungstest prüft nicht, was das System tun sollte. Er hält fest, was das System heute tatsächlich tut, und schlägt fehl, sobald sich dieses Verhalten ändert.

Dieser Unterschied ist entscheidend. In Legacy-Systemen fehlt die Spezifikation häufig, ist veraltet oder wird durch jahrelange Patches widerlegt. Kunden verlassen sich unter Umständen sogar auf ein Verhalten, das ursprünglich ein Fehler war. Charakterisierungstests akzeptieren das aktuelle Verhalten als Referenz, sodass jede Änderung beim Refactoring sichtbar und bewusst erfolgt statt versehentlich.

In der Praxis gibt es verschiedene Formen:

• Tests auf Unit-Ebene, die einzelne Funktionen oder Klassen mit repräsentativen Eingaben aufrufen und die aktuellen Ergebnisse festschreiben.
• Golden-Master-Tests, die eine große Menge an Eingaben durch ein Modul oder das gesamte System schicken und die vollständige Ausgabe mit einer gespeicherten Referenz vergleichen.
• Tests auf API- oder Integrationsebene, die erfassen, wie Dienste auf Anfragen reagieren, einschließlich Fehlerbehandlung und Sonderfällen.

Sobald dieses Netz steht, ist Refactoring kein Sprung ins Ungewisse mehr. Ändert sich das Verhalten, schlägt ein Test fehl, und das Team kann entscheiden, ob die Änderung beabsichtigt war.

Wo KI die Wirtschaftlichkeit verändert

Charakterisierungstests waren schon immer eine gute Idee mit einem praktischen Problem: Sie kosten viel Zeit. Ein Entwickler muss unbekannten Code lesen, Ausführungspfade nachvollziehen, sinnvolle Eingaben finden, Abhängigkeiten isolieren und die Prüfungen schreiben. Bei einer großen Codebasis konnte das Monate dauern, bevor eine sichtbare Verbesserung eintrat.

KI-Werkzeuge verschieben dieses Verhältnis auf mehreren konkreten Ebenen.

Codeverständnis im großen Maßstab. KI kann ein Modul lesen, zusammenfassen, was es offenbar tut, seine Verzweigungen auflisten und versteckte Abhängigkeiten wie Datenbankzugriffe, Dateioperationen oder globale Zustände aufzeigen. Das verkürzt den zeitaufwendigsten Teil der Arbeit: das Verstehen des Codes.

Systematische Suche nach Eingaben. KI schlägt zuverlässig Eingaben vor, die unterschiedliche Pfade durchlaufen, darunter Grenzwerte, leere Sammlungen, ungültige Formate und ungewöhnliche Kombinationen, an die ein Entwickler unter Zeitdruck womöglich nicht denkt.

Testgerüste und Isolation. Ein Großteil des Aufwands beim Testen von Legacy-Code entfällt auf den Aufbau von Testumgebungen, die Erstellung von Test-Doubles und das Aufbrechen von Abhängigkeiten. KI erzeugt diesen Standardcode schnell und einheitlich über viele Module hinweg.

Dokumentation als Nebenprodukt. Dieselbe Analyse, aus der die Tests entstehen, liefert auch verständliche Beschreibungen des Codeverhaltens. Bei einem System ohne Dokumentation ist schon das ein erheblicher Gewinn.

Nach unserer Erfahrung können Teams, die KI-gestützte Testgenerierung in einem strukturierten Entwicklungsprozess einsetzen, die automatisierte Testabdeckung innerhalb weniger Wochen deutlich erhöhen. In einem Projekt, das wir auf unserer Seite zur KI-gestützten Softwareentwicklung beschreiben, stieg die Abdeckung durch automatisierte Tests um rund 15 bis 20 Prozentpunkte. Der Gewinn entsteht aus der Verbindung von KI-Geschwindigkeit und Engineering-Urteilsvermögen, nicht aus KI allein.

Wo KI an ihre Grenzen stößt

KI-generierte Tests bringen spezifische Risiken mit sich, die Teams bewusst steuern müssen. Wer sie ignoriert, erzeugt eine trügerische Sicherheit, und die ist schlimmer als gar keine Tests.

Prüfungen auf Basis von Annahmen statt Beobachtungen. Ein KI-Werkzeug formuliert eine Erwartung womöglich auf Grundlage dessen, was der Code seiner Einschätzung nach zurückgibt. Für Charakterisierungstests ist das ein grundlegender Fehler. Erwartete Werte müssen aus der tatsächlichen Ausführung des bestehenden Codes stammen, nicht aus der Interpretation des Modells.

Schwache Tests, die immer bestehen. Tests können Code ausführen, ohne etwas Aussagekräftiges zu prüfen. Sie treiben die Abdeckungswerte nach oben, sichern aber nichts ab. Hohe Abdeckung ist nicht dasselbe wie ein belastbares Sicherheitsnetz.

Nicht deterministisches Verhalten. Legacy-Code hängt häufig von der aktuellen Uhrzeit, Zufallswerten, externen Diensten oder gemeinsam genutzten Zuständen ab. Tests, die das ignorieren, werden instabil, und instabile Tests werden vom Team schnell ignoriert.

Sensible Daten. Golden-Master-Ansätze greifen mitunter auf produktionsnahe Daten zurück. Echte Kundendaten in Testdaten oder KI-Werkzeuge zu übernehmen, wirft Fragen zu Vertraulichkeit und DSGVO auf. Daten sollten anonymisiert oder synthetisch erzeugt werden.

Vertraulichkeit des Codes. Wer proprietären Code in KI-Werkzeuge eingibt, braucht freigegebene Tools mit passenden Enterprise-Bedingungen und klare Regeln dafür, was geteilt werden darf.

Ein praxistauglicher Prozess für KI-generierte Charakterisierungstests

Ein verlässliches Vorgehen verbindet KI-Generierung mit Prüfschritten, die die Ergebnisse ehrlich halten.

1. Den richtigen Startpunkt wählen. Versuchen Sie nicht, das gesamte System auf einmal abzudecken. Konzentrieren Sie sich auf Module, die hohe geschäftliche Bedeutung, häufige Änderungen und hohe Komplexität vereinen. Dort zahlt sich ein Sicherheitsnetz zuerst aus, und dort ist Refactoring meist am dringendsten.

2. Das Verhalten von der KI kartieren lassen. Lassen Sie die KI das ausgewählte Modul analysieren, seine Aufgaben beschreiben, Ausführungspfade und Abhängigkeiten auflisten und passende Testszenarien vorschlagen. Ein Entwickler prüft diese Übersicht und korrigiert oder ergänzt sie.

3. Tests erzeugen und reale Ergebnisse festschreiben. Die KI erzeugt Testcode und Eingaben, die erwarteten Werte werden jedoch durch Ausführung des bestehenden Codes ermittelt. Jeder Charakterisierungstest muss gegen das aktuelle System bestehen, bevor er übernommen wird.

4. Die Tests stabilisieren. Kontrollieren Sie Uhrzeit, Zufallswerte und externe Aufrufe durch Test-Doubles oder feste Konfigurationen. Führen Sie die Testsuite mehrfach aus, um instabile Tests früh zu erkennen.

5. Prüfen, ob die Tests wirklich absichern. Die Abdeckung zeigt, welche Zeilen ausgeführt wurden, nicht aber, ob die Tests eine Änderung erkennen würden. Mutationstests, die gezielt kleine Änderungen in den Code einbauen und prüfen, ob die Tests fehlschlagen, sind ein weitaus besseres Maß dafür, wie stark das Sicherheitsnetz tatsächlich ist.

6. In die Pipeline integrieren. Charakterisierungstests helfen nur, wenn sie bei jeder Änderung automatisch laufen. Werden sie in die CI/CD-Pipeline eingebunden, unterstützt durch solide DevOps- und Cloud-Praktiken, werden sie zu einem dauerhaften Schutz statt zu einer einmaligen Übung.

7. Refactoring durchführen und die Tests weiterentwickeln. Mit dem Netz im Rücken kann das Team in kleinen, überprüfbaren Schritten umbauen. Mit der Zeit werden Charakterisierungstests schrittweise durch Tests ersetzt oder ergänzt, die das beabsichtigte Verhalten beschreiben, insbesondere dort, wo das Team feststellt, dass das bisherige Verhalten eigentlich ein Fehler war.

Woran Sie erkennen, ob das Sicherheitsnetz ausreicht

Bevor größere strukturelle Änderungen beginnen, lohnt sich ein Abgleich mit einigen einfachen Kriterien:

Lässt sich die Mehrheit dieser Fragen mit Ja beantworten, kann das Team mit Zuversicht umbauen. Andernfalls gilt: Es ist besser, das Netz zu verstärken, als die Modernisierung zu früh zu beginnen.

Charakterisierungstests als Teil einer umfassenden Modernisierungsstrategie

Charakterisierungstests sind kein Selbstzweck. Sie bilden das Fundament für alles, was folgt: Refactoring, den schrittweisen Austausch von Komponenten, die Migration auf neue Architekturen oder KI-gestützte Codetransformation.

Zugleich machen sie Modernisierungspläne glaubwürdiger. Ein Team, das ein stabiles Sicherheitsnetz um seine kritischen Module nachweisen kann, schätzt den Refactoring-Aufwand genauer, bewältigt größere Änderungen mit geringerem Risiko und belegt Fortschritte gegenüber der Geschäftsführung mit harten Daten. Dieselben Nachweise sind auch in einer technischen Due Diligence wertvoll, denn Testabdeckung und die Fähigkeit, Code sicher zu ändern, sind zentrale Signale dafür, was ein Produkt tatsächlich wert ist.

Für Unternehmen, die nicht sicher sind, wo sie anfangen sollen, hilft ein AI Refactoring Assessment: Es zeigt, bei welchen Modulen ein Sicherheitsnetz am wichtigsten ist, schätzt den Aufwand und klärt, welche Teile des Systems umgebaut, ersetzt oder unverändert gelassen werden sollten.

Modernisieren mit Netz statt mit Sprung ins Ungewisse

Legacy-Systeme werden durch Abwarten nicht sicherer. Jedes Jahr ohne Tests bringt mehr undokumentiertes Verhalten, mehr Workarounds und eine stärkere Abhängigkeit von einem immer kleineren Kreis von Menschen, die den Code verstehen. KI ersetzt keine Engineering-Disziplin, macht aber den ersten und wichtigsten Schritt deutlich günstiger: festzuhalten, was das System heute tut.

Teams, die einige Wochen in ein vertrauenswürdiges Sicherheitsnetz investieren, gewinnen etwas, das auf anderem Weg kaum zu erreichen ist: die Freiheit, ihre Kernsysteme ohne Angst zu verändern. Wenn Sie ein kritisches System modernisieren möchten, ohne zu gefährden, was bereits funktioniert, erfahren Sie auf unserer Seite zur Produkt- und Anwendungsentwicklung, wie unsere Teams dieses Netz aufbauen und die Modernisierung vorantreiben.