Tests für Code, den niemand mehr versteht: Charakterisierungstests in der Praxis
Der übliche Einwand gegen jede Änderung an einem Altsystem lautet: Wir wissen nicht, was dabei kaputtgeht. Der Einwand ist berechtigt, und er lässt sich auflösen, ohne dass vorher jemand das System versteht.
Charakterisierungstests halten das heutige Verhalten eines Systems fest, ohne zu bewerten, ob es korrekt ist. Sie sind der einzige gangbare Einstieg bei unverstandenem Code, weil fachliche Tests Fachkenntnis voraussetzen. Die besten Eingaben sind anonymisierte Produktivdaten, danach Schnittstellenprotokolle, zuletzt konstruierte Fälle. Modelle helfen beim Umfang, nicht bei der Auswahl der abzudeckenden Pfade — die folgt dem Schaden. Geprüft wird das Netz mit einer absichtlichen Änderung mit bekannter Wirkung.
Was ein Charakterisierungstest ist
Ein Test, der festhält, was das System heute tut — ohne Aussage darüber, ob es das Richtige tut. Man gibt Eingaben hinein, protokolliert die Ausgaben und schreibt beides als Erwartung fest. Ändert sich das Verhalten nach einem Eingriff, schlägt der Test fehl. Ob das gut oder schlecht ist, entscheidet danach ein Mensch.
Warum das der einzige gangbare Einstieg ist
Fachliche Tests setzen voraus, dass jemand die Fachlichkeit kennt. Genau das ist bei einem unverstandenen Bestand nicht gegeben. Charakterisierungstests kehren die Reihenfolge um: Erst entsteht das Netz, dann darf man sich bewegen, und beim Bewegen lernt man die Fachlichkeit. Ohne diesen Schritt bleibt jede Modernisierung eine Serie von Wetten.
Wie man an die Eingaben kommt
Drei Wege, in dieser Reihenfolge. Produktivdaten in anonymisierter Form sind die beste Quelle, weil sie die tatsächliche Verteilung abbilden, inklusive der Sonderfälle, die niemand erfunden hätte. Protokolle von Schnittstellenaufrufen sind die zweite Wahl. Erst danach kommen konstruierte Fälle, und die decken erfahrungsgemäß genau die Ränder nicht ab, um die es geht.
Wo Modelle hier tatsächlich helfen
Beim Umfang. Für einen Bestand ohne Tests lassen sich in großer Zahl Testgerüste erzeugen — das ist stumpfe Arbeit in einer Menge, die manuell niemand bezahlt. Was die Modelle nicht leisten: die Auswahl, welche Pfade überhaupt abgedeckt sein müssen. Diese Auswahl folgt dem Schaden, und der steht nicht im Code.
Woran man merkt, dass das Netz trägt
An der ersten absichtlichen Änderung. Man ändert etwas Kleines, das eine bekannte Wirkung haben muss, und prüft, ob genau die erwarteten Tests fehlschlagen — nicht mehr und nicht weniger. Schlägt nichts fehl, deckt das Netz die Stelle nicht ab. Schlägt alles fehl, sind die Tests zu eng an Nebensächlichkeiten gebunden.
Häufige Fragen
Wie unterscheiden sich Charakterisierungstests von Regressionstests?
Ein Regressionstest prüft gegen ein gewünschtes Verhalten, ein Charakterisierungstest gegen das vorgefundene. Der Unterschied ist die Aussage: Der eine sagt „so soll es sein", der andere „so war es gestern". Bei unverstandenem Code ist nur die zweite Aussage ehrlich möglich.
Was tun, wenn ein Charakterisierungstest ein falsches Verhalten festschreibt?
Genau das ist beabsichtigt. Das Netz hält auch Fehler fest, damit man sie bewusst ändern kann statt versehentlich. Sobald ein Fachbereich bestätigt, dass ein Verhalten falsch ist, wird der Test angepasst — mit Begründung und Datum, und damit ist die Entscheidung dokumentiert.
Braucht man dafür Produktivdaten?
Anonymisierte Auszüge sind die beste Quelle, weil sie die reale Verteilung enthalten. Wo das nicht geht, sind Schnittstellenprotokolle brauchbar. Konstruierte Testfälle sind die schwächste Variante: Sie enthalten genau die Sonderfälle nicht, wegen derer man das Netz baut.
Wie viele Tests braucht man, bevor man anfangen kann?
Nicht viele, aber die richtigen. Sinnvoll ist eine Abdeckung der Pfade mit dem höchsten Schaden — Geldflüsse, Fristen, Außenschnittstellen — und ein bewusster Verzicht auf den Rest. Vollständigkeit ist bei einem großen Altbestand kein erreichbares Ziel und auch nicht nötig.
Rechnen Sie es für Ihre Organisation durch.
Vierzehn Angaben, fünf Minuten: Prüflücke, Legacy-Risiko und die Reihenfolge.
Engineering-Check starten →
