Das Auftragsbuch läuft seit Jahren. Frau Aydin, die Disponentin, vertraut darauf, dass die Rechnung für Herrn Kowalskis Wasserhahn-Tausch am Ende genau den Betrag zeigt, den sie kennt. Im nächsten Modul tauschen Sie die Laufzeit unter dem Programm aus, die Pakete und Teile des Codes. Jede dieser Änderungen kann etwas verändern, das niemand wollte, und dann merkt es keiner, bis jemand anruft.

Deshalb kommt das Sicherheitsnetz zuerst. In dieser Lektion bauen Sie es für das Auftragsbuch auf, noch bevor Sie eine Zeile ändern. Es besteht aus fünf Teilen: einem eingefrorenen Stand, einer Testkopie der Datenbank, Tests, die das heutige Verhalten festhalten, einer Möglichkeit, Formulare in Tests zu erzeugen, und einer Checkliste für jeden Schritt. Am Ende ist das Programm unverändert (bis auf zwei winzige Stellen) und trotzdem sicherer zu ändern.

Die Grundlagen von xUnit setzen wir voraus (K1, Modul „Tests“, und K2, Modul 2.7 „Testen im Web“). Hier geht es nur um das, was bei einem gewachsenen Programm anders ist.

Charakterisierungstests: festhalten, was ist

Ein normaler Test beschreibt, was ein Programm tun soll. Ein Charakterisierungstest beschreibt, was es heute tut. Das ist ein Unterschied, der bei Modernisierungen wichtig wird, denn Sie wissen oft nicht, ob eine Regel gewollt ist oder zufällig so entstand. Die Rechnung, die Frau Aydin kennt, ist das Ergebnis des Programms, nicht das einer Spezifikation. Ändert sich der Betrag um einen Cent, ist das für die Betriebe, die damit arbeiten, ein Fehler, auch wenn die neue Zahl „richtiger“ wäre.

Das Vorgehen ist immer gleich:

  1. Sie rufen den Code mit einer Eingabe auf, die im Betrieb vorkommt.
  2. Sie schreiben als erwartetes Ergebnis zunächst irgendeinen Wert hin, und der Test wird rot.
  3. Sie lesen den echten Wert aus der Fehlermeldung, tragen ihn ein, und der Test wird grün.
  4. Sie schreiben in einem Kommentar dazu, falls das Ergebnis überrascht.
Normaler Test Charakterisierungstest
Frage Tut der Code, was er soll? Tut der Code noch, was er heute tut?
Erwartungswert aus der Anforderung aus dem laufenden Programm
Ein überraschendes Ergebnis ist ein Fehler im Code wird festgehalten und erst später entschieden
Wann er rot werden darf wenn der Code falsch ist wenn Sie das Verhalten absichtlich ändern

Ein Beispiel aus dem Auftragsbuch: Das Material wird mit einem Aufschlag von 15 Prozent berechnet und mit Math.Round auf zwei Stellen gerundet. Bei 0,30 Material ergibt das 0,345, und Math.Round rundet ohne weitere Angabe zur geraden Ziffer, also auf 0,34 und nicht auf 0,35. Ein Mensch würde 0,35 erwarten. Das Programm rechnet seit Jahren mit 0,34, und alle gedruckten Rechnungen stimmen damit. Der Test schreibt 0,34 auf und markiert es als Eigenheit.