Charakterisierungstests: festhalten, was Legacy-Code tatsächlich tut

Ziel

Ein Sicherheitsnetz um Code legen, dessen beabsichtigtes Verhalten unbekannt oder undokumentiert ist, damit er mit der Gewissheit refaktoriert oder ersetzt werden kann, dass sich das beobachtbare Verhalten nicht geändert hat.

Voraussetzungen

Der Code lässt sich aus einem Testrahmen aufrufen, gegebenenfalls nachdem eine Abhängigkeit über eine Nahtstelle (ein Parameter, eine Umgebungsvariable, ein injizierter Mitwirkender) aufgebrochen wurde; Eingaben lassen sich aus der Produktion erfassen oder konstruieren; der Code lässt sich wiederholt ohne Schaden ausführen.

Schritte

1. Eine Einheit mit klarer Grenze wählen (eine Funktion, ein Request-Handler, ein Batch-Job) und ihre Eingaben und beobachtbaren Ausgaben auflisten, einschliesslich Nebenwirkungen: geschriebene Dateien, geänderte Zeilen, gesendete Nachrichten.
2. Einen Test mit einer Platzhaltererwartung schreiben und ausführen. Feathers beschreibt, mit einem Test namens x und einem Dummy-Erwartungswert zu beginnen, den tatsächlichen Wert aus dem fehlgeschlagenen Assert abzulesen, ihn in den Test einzufügen und den Test anschliessend so umzubenennen, dass er beschreibt, was der Code tut.
3. Dasselbe für Eingaben wiederholen, die andere Zweige erreichen: leer, Randwert, fehlerhaft, gross, ungewöhnliche Kodierungen. Coverage nutzen, um Zweige zu finden, die noch kein Test erreicht hat.
4. Bei grossen Ausgaben die serialisierte Ausgabe in einer Snapshot- oder Approval-Datei ablegen, wobei flüchtige Felder (Zeitstempel, IDs) geschwärzt werden; die Datei bleibt unter Beobachtung.
5. Überraschungen festhalten, ohne sie zu beheben. Feathers' Punkt ist, dass der Zweck darin besteht, das tatsächliche Verhalten des Systems zu dokumentieren, nicht das gewünschte; etwas, das wie ein Fehler wirkt, kann anderswo vorausgesetzt werden. Eine Liste vermuteter Fehler führen, die mit den Verantwortlichen des Systems zu entscheiden sind.
6. Die Testsuite vor und nach jedem Refactoring-Schritt ausführen. Jede veränderte Ausgabe ist entweder ein Versehen oder eine Entscheidung; eine Entscheidung erhält ein Ticket und einen aktualisierten Test, dessen Name begründet, warum.
7. Sobald das beabsichtigte Verhalten bekannt ist, Tests zu Spezifikationstests verschärfen und Charakterisierungstests löschen, die nur beiläufige Ausgaben festgehalten haben.

Erwartetes Ergebnis

Eine Suite, die bei jeder Änderung des beobachtbaren Verhaltens fehlschlägt, eine Liste vermuteter Fehler mit Verantwortlichen, und die Freiheit, den Code umzustrukturieren.

Grenzen und Prüfbasis

Charakterisierungstests halten beiläufiges Verhalten fest (Reihenfolge, Formatierung), weshalb sie bei harmlosen Änderungen fehlschlagen und überarbeitet werden müssen. Sie decken nur die Eingaben ab, an die jemand gedacht hat; Stichproben aus Produktionsdaten erweitern das. Das Aufbrechen von Abhängigkeiten, um an den Code zu gelangen, ist der schwierige Teil und kann selbst kleine, ungeschützte Änderungen erfordern. Es wird keine Messung behauptet.