Antwort.

Die Automatisierung von Tests für Legacy-Code ist eines der größten klassischen Probleme im IT-Bereich.

Geschichte der Frage: Viele Unternehmen sehen sich der Notwendigkeit gegenüber, Systeme zu testen, die ohne Berücksichtigung zukünftiger Automatisierung entwickelt wurden. Oft haben solche Projekte schwache Dokumentation, hohe technische Schulden und einen Mangel an isolierten Komponenten.

Problem: Die Hauptschwierigkeiten ergeben sich aus

fehlenden Test-Hooks und Integrationspunkten
der Unmöglichkeit, Daten für Tests zu isolieren
starker Abhängigkeit zwischen Modulen
einer großen Anzahl von Anomalien und Änderungen, die nicht im Code reflektiert sind.

Lösung: Normalerweise erfolgt der Prozess schrittweise:

Systemanalyse: Es ist erforderlich, kritische Geschäftsprozesse zu identifizieren und den Testumfang zu vereinbaren.
Einführung von Testpunkten: Wo möglich, wird ein Teil des Codes mit Proxys umhüllt, an Test-Doubles angepasst oder das Muster der Abhängigkeitseinfügung verwendet.
Schrittweiser Testaufbau: Zunächst werden Tests für den "einfachsten" und am wenigsten verbundenen Code geschrieben.
Ständige Unterstützung und Refactoring: Nach der Hinzufügung von Tests werden sie als Sicherheitsnetz für Verbesserungen genutzt.

Schlüsselfeatures:

Tests werden häufig nicht von Grund auf neu geschrieben, sondern auf "Wrapper" über bestehenden Funktionen.
Die Testbarkeit muss schrittweise in die Architektur eingeführt werden.
Das Geschäft sollte maximal in die Regelung kritischer Szenarien eingebunden sein.

Fangfragen.

Kann man anfangen, automatisierte Tests zu schreiben, bevor der Legacy-Code vollständig refaktoriert ist?

Ja, oft sind automatisierte Tests genau dafür erforderlich, um das Refactoring abzusichern. Man darf nicht auf "vollständige Perfektion" warten – im Gegenteil, Tests helfen, mutig Veränderungen vorzunehmen.

Sollte man sofort versuchen, gesamten Legacy-Code mit automatisierten Tests abzudecken?

Nein. Es sollte der Fokus auf den riskantesten und am häufigsten verwendeten Szenarien liegen. Eine "alles umfassende" Abdeckung schadet der Geschwindigkeit und hat keinen Sinn.

Muss man moderne Muster wie DI einführen, um Legacy-Code zu testen?

Nein, aber es wird empfohlen, sie zu verwenden, wenn die Ressourcen dies zulassen. Der erste Schritt ist zumindest teilweise Isolation, Mocks und spezielle Testpunkte im Code.

Typische Fehler und Anti-Patterns

Migration des gesamten Codes gleichzeitig für automatisierte Tests – Projekte stoppen und verlieren ihren geschäftlichen Sinn.
"Paranoides" Abdecken unwichtiger Funktionen.
Fehlende Kommunikation zwischen Entwicklung, Testing und Geschäft.

Beispiel aus dem Leben

Negativer Fall

Das Team versuchte, automatisierte Tests einzuführen, indem es die gesamte alte Anwendung nach SOLID-Mustern neu schrieb und 100 % des Codes testete.

Vorteile:

Grundlegende Verbesserung der Architektur.
Langfristig können Tests nützlich sein.

Nachteile:

Entwicklungspause von mehreren Monaten.
Ständige Bugs und Desynchronisation mit den Geschäftsanforderungen.
Veralteter Code zum Zeitpunkt, an dem die Tests geschrieben sind.

Positiver Fall

Automatisierte Tests wurden nur für die Schlüsselberechnungsstellen eingeführt, unter gleichzeitiger Einführung spezieller Stabs, wobei der allgemeine Code minimal geändert wurde.