Glossar
Characterization Tests
Auch: Approval Tests · Golden Master · Charakterisierungstests
Tests, die festhalten, was ein System heute tut, statt zu prüfen, was es tun sollte. Das Sicherheitsnetz vor der ersten Änderung.
Der Unterschied zu gewöhnlichen Tests ist die Richtung. Ein normaler Test prüft eine Erwartung: Diese Eingabe soll dieses Ergebnis liefern. Ein Characterization Test hält fest, was tatsächlich herauskommt, ohne Urteil darüber, ob es richtig ist. Er dokumentiert Ist-Verhalten.
Das klingt nach einem Kompromiss und ist genau das Richtige, wenn niemand mehr weiß, was ein System tun soll. In gewachsenen Systemen ist das der Normalfall: Es gibt keine Spezifikation, die Anforderungen sind zwanzig Jahre alt, und der Code ist die einzige verlässliche Quelle darüber, was passiert.
Praktisch entstehen sie, indem man reale Eingaben durch das System schickt und die Ausgaben als erwartetes Ergebnis festschreibt. Bei größeren Ausgaben, etwa ganzen Dokumenten oder JSON-Strukturen, vergleicht man gegen eine abgelegte Referenzdatei, daher der Name Golden Master.
Der Wert zeigt sich beim ersten Refactoring. Ohne dieses Netz ist jede Umstrukturierung eine Wette darauf, dass man alles verstanden hat. Mit ihm wird eine unbeabsichtigte Verhaltensänderung sofort sichtbar, und zwar an der Stelle, an der sie entstanden ist, nicht drei Wochen später im Betrieb.
Die Tests sind ausdrücklich Wegwerfware. Wenn ein Bereich modernisiert und mit echten Tests versehen ist, dürfen sie verschwinden. Sie sind ein Gerüst für den Umbau, kein dauerhaftes Qualitätsinstrument.
Eine Fußangel: Sie zementieren auch Fehler. Findet sich beim Anlegen ein offensichtlich falsches Verhalten, wird es trotzdem zuerst festgeschrieben und getrennt zur Entscheidung gestellt. Wer es sofort korrigiert, vermischt Absicherung und Änderung und verliert genau den Nutzen.
Woran Sie es erkennen
- Ein Bereich soll geändert werden, hat aber keine Tests.
- Es gibt keine Spezifikation, oder sie ist erkennbar veraltet.
- Niemand kann verlässlich sagen, was das System in Randfällen tut.
- Frühere Änderungen führten zu Überraschungen in scheinbar unbeteiligten Bereichen.
Nicht zu verwechseln mit
- Unit-Test
- Prüft eine Erwartung an eine kleine Einheit. Setzt voraus, dass man weiß, was richtig ist. Genau dieses Wissen fehlt bei Legacy.
- Integrationstest
- Prüft das Zusammenspiel gegen definierte Erwartungen. Characterization Tests liegen oft auf derselben Ebene, aber ohne Erwartung: sie schreiben auf, was ist.
- Snapshot-Test
- Technisch dasselbe Prinzip, meist auf Oberflächen bezogen. Der Begriff Characterization betont den Zweck: ein unbekanntes System vor dem Umbau absichern.
Wann es trägt
- Vor der ersten Änderung an einem Bereich ohne Tests.
- Wenn das Sollverhalten nicht dokumentiert ist und niemand es sicher kennt.
- Vor einer Ablösung, damit das neue System gegen dasselbe Verhalten geprüft werden kann.
Wann nicht
- In Bereichen mit vorhandenen, aussagekräftigen Tests.
- Als dauerhafter Ersatz für echte Tests. Sie sind ein Gerüst, kein Fundament.
- Für Code, der ohne Ersatz abgeschaltet wird.
Wie man rangeht
- Echte Eingaben sammelnAus Protokollen, aus der Datenbank, aus dem laufenden Verkehr. Erfundene Beispiele treffen die Sonderfälle nicht, und die Sonderfälle sind der Grund für die Übung.
- Ausgaben festschreiben, ohne zu urteilenWas herauskommt, wird zum erwarteten Ergebnis, auch wenn es merkwürdig aussieht. Die Bewertung kommt später und getrennt.
- Auffälligkeiten notieren, nicht korrigierenEine Liste der Stellen, die falsch wirken, mit Fundort. Sie ist die Grundlage für ein fachliches Gespräch, nicht für einen sofortigen Fix.
- Abdeckung an der Änderung ausrichtenNicht das ganze System absichern, sondern den Bereich, der angefasst wird, plus seine Ränder. Vollständigkeit ist hier kein Ziel.
- In die Pipeline nehmenDer Test nützt nur, wenn er bei jeder Änderung läuft. Ein lokal ausgeführtes Skript ist nach zwei Wochen vergessen.
- Nach der Modernisierung ersetzenSobald echte Tests existieren, dürfen die Charakterisierungstests weg. Sie dauerhaft zu pflegen zementiert Verhalten, das niemand mehr will.
Häufig gefragt
Was, wenn das festgehaltene Verhalten falsch ist?
Trotzdem festhalten und getrennt notieren. Das Netz soll unbeabsichtigte Änderungen sichtbar machen, nicht Richtigkeit garantieren. Ob ein Verhalten korrigiert wird, ist eine fachliche Entscheidung mit eigenen Folgen, und manchmal lautet die Antwort: bleibt so, weil Kunden darauf aufgebaut haben.
Wie viel Abdeckung braucht man?
So viel, wie der geplante Eingriff berührt, plus die Ränder. Ein vollständiges Netz über ein großes Altsystem zu spannen dauert Monate und wird nie fertig. Die Tests entstehen dort, wo als Nächstes gearbeitet wird.
Ersetzen Characterization Tests echte Tests?
Nein, sie überbrücken. Sobald ein Bereich modernisiert ist und klar ist, was er tun soll, gehören richtige Tests mit echten Erwartungen dorthin. Die Charakterisierungstests dürfen dann verschwinden, sonst zementieren sie Verhalten, das gerade abgeschafft wurde.
Funktioniert das auch ohne Testumgebung?
Es geht auch mit einem Skript, das Eingaben durchschickt und Ausgaben in Dateien ablegt, die versioniert werden. Wichtig ist nur, dass es automatisch bei jeder Änderung läuft. Ein Vergleich, den jemand von Hand anstoßen muss, findet unter Termindruck nicht statt.