Tests: Code ändern, ohne Angst zu haben

Es ist 23 Uhr. Du musst ändern, wie der Warenkorb den Rabatt berechnet. Die Funktion ist vierzig Zeilen lang, geschrieben von jemandem, der die Firma verlassen hat, und sie liefert den Preis auf jeder Seite der Website. Du änderst zwei Zeilen und musst jetzt herausfinden, ob du etwas kaputt gemacht hast. Es gibt zwei Arten zu leben: die Seite öffnen, jede Seite von Hand durchklicken und hoffen, keine vergessen zu haben — oder einen Befehl ausführen und in zwei Sekunden eine Antwort bekommen. Das Zweite ist keine Magie. Das sind Tests.

Ein Test ist eine Behauptung in einer Form, die eine Maschine prüfen kann. Du sagst: Für diese Eingaben muss diese Funktion jene Antwort liefern. Dann führst du ihn aus. Stimmt die Antwort, hat die Behauptung gehalten. Stimmt sie nicht, hast du gerade etwas gelernt. Ein Test beweist nicht, dass der Code korrekt ist — er ist eine Liste konkreter Versprechen, die jedes Mal automatisch geprüft werden.

vat(net, rate) = net * (1 + rate)

assert priceWithVat(100, 0.21) === 121
assert priceWithVat(0, 0.21) === 0
assert priceWithVat(100, 0) === 100

assert x == y
  FAIL at line 6

Nicht alle Tests sind gleich groß. Ein Unit-Test nimmt ein kleines Stück Code — meist eine Funktion — und füttert es mit Eingaben, während sonst nichts beteiligt ist: kein Netzwerk, keine Datenbank, kein Browser. Er läuft in Sekundenbruchteilen, und wenn er rot wird, weißt du genau, welche Funktion kaputt ist. Ein Integrationstest lässt mehrere echte Teile zusammen laufen: deinen Code plus eine echte Datenbank, oder deinen Code, der über das Netzwerk mit einem anderen Dienst spricht. Er ist langsamer, er kann aus Gründen scheitern, die nichts mit deiner Änderung zu tun haben, und er fängt eine völlig andere Art von Fehler — die, die erst auftaucht, wenn die Teile zusammengeschlossen sind. Du brauchst beide, und du musst wissen, welchen du gerade vor dir hast.

Das ist der Teil, der Leute überrascht: Ein fehlgeschlagener Test ist eine gute Nachricht. Ein roter Test heißt, die Maschine hat einen Unterschied gefunden zwischen dem, was du versprochen hast, und dem, was der Code tut — und sie hat ihn jetzt gefunden, auf deinem Laptop, in zwei Sekunden, statt nächsten Donnerstag vor einem Kunden. Die unangenehme Variante desselben Fehlers ist die, für die niemand getestet hat: Sie erreicht echte Menschen, und du erfährst davon durch eine Nachricht, die mit „hey, ist die Seite bei dir auch kaputt?“ beginnt.

Der eigentliche Grund, warum Teams Tests schreiben, hat nichts mit Fehlersuche zu tun. Er ist die Angst. In einer Codebasis ohne Tests ist jede Änderung ein Glücksspiel, also machen Leute die kleinstmöglichen Änderungen und fassen nichts an, was funktioniert — auch nicht die hässlichen Stellen, die dringend neu geschrieben werden müssten. Mit Tests kannst du eine Funktion ändern, die Suite laufen lassen und in Sekunden wissen, ob du den Rest kaputt gemacht hast. Genau das macht Aufräumen und Verbessern überhaupt möglich. Tests sind kein Bericht für eine Lehrkraft. Sie sind das, was dich bewegen lässt.