Reparieren von Legacy-Code – Automatisch

Viele Projekte verwenden bereits automatisierte Regressionstests. Leider ist das genau dann nicht gegeben, wenn man es am nötigsten hat, nämlich bei Übernahme von fremdem (ungetesteten) Legacy-Code. Hier wünsche ich mir nicht nur automatisierte Regressionstests, sondern auch automatisierte Testerstellung. Warum gibt es so etwas nicht?

Ich vermute schon, dass viele Software-Entwickler das einfach damit begründen würden, dass Code einfach zu komplex ist, um ihn automatisch aufräumen zu können. Tatsächlich ist Komplexität ein starkes Hindernis für Automatisierung – Automatisierung ist etwas für eintönige einfache Aufgaben.

Allerdings – Tests-Schreiben für Legacy-Code ist doch ziemlich eintönig:

• man wählt die Methode aus, die man testen möchte
• man findet heraus welcher Zustand diese Methode beeinflusst (Vor-Zustand)
• man findet heraus welcher Zustand von der Methode beeinflusst wird (Nach-Zustand)
• man tested die Methode mit verschiedenen Vor-Zuständen und prüft ob die Methode den erwarteten Nach-Zustand erzeugt hat

Die Schwierigkeiten hierbei sind:

• die Beschränkungen der Programmiersprache (z.B. kann Information Hiding der Zugriff auf Vor/Nach-Zustände behindert werden)
• die schiere Größe der Vor/Nachzustände (gerade bei Legacy Code sind solche Zustände sehr groß)

Beide Probleme sind für Menschen problematischer als für ein automatisches Werkzeug. Und man sollte meinen, dass es ein solches Werkzeug schon gibt. Das einfache Suchen im Internet nach Tools, die Zustände serialisieren, Tests generieren oder Tests aufzeichnen ergab nichts. Also habe ich meinen eigenen Prototypen angefangen.

Meine Lösung für Java ist testrecorder. Fortschritte (die über Versionsupdate hinaus gehen) werde ich weiter auf diesem Blog posten.