Testgetriebene Entwicklung: Warum sich Tests von Anfang an lohnen

Testgetriebene Entwicklung (TDD) ist die meistmissverstandene Methode der Softwareentwicklung. Sie ist kein Testwerkzeug, sondern ein Designwerkzeug: Der Test, der zuerst scheitert, zwingt dich, die Schnittstelle zu entwerfen, bevor du die Implementierung schreibst. Die Tests sind der Nebeneffekt – das bessere Design ist der eigentliche Gewinn.

Der rote-grüne-refactor-Zyklus

TDD folgt einem strengen, kurzen Rhythmus – und genau diese Kürze ist der Punkt. Kein Zyklus dauert länger als ein paar Minuten:

• Rot: Schreibe einen minimalen Test für das nächste Verhalten, das du willst. Führe ihn aus. Er muss scheitern – sonst testet er nichts Neues.
• Grün: Schreibe die einfachste Implementierung, die den Test bestehen lässt. Einfach heißt auch: hässlich, dupliziert, primitiv. Kein Blick über den Tellerrand.
• Refactor: Räume auf. Duplikation entfernen, Namen verbessern, Struktur glätten – die Tests sichern dich dabei ab.

// 1. ROT: Der Test beschreibt das gewünschte Verhalten
public function testRabattFuerStammkunde(): void
{
    $kunde = new Kunde(stammkunde: true);
    $rechnung = new Rechnung(betrag: 100.0, kunde: $kunde);

    $this->assertSame(90.0, $rechnung->endbetrag());
}

// 2. GRÜN: Die einfachste Lösung, die den Test erfüllt
public function endbetrag(): float
{
    return $this->betrag * 0.9;   // Stammkunden-Rabatt – erstmal hart
}

// 3. REFACTOR: Rabatt-Logik extrahieren, Tests laufen weiter
public function endbetrag(): float
{
    return $this->betrag * (1 - $this->kunde->rabattsatz());
}

Warum zuerst der Test?

Wer zuerst implementiert und dann testet, testet unbewusst das, was der Code schon tut – nicht das, was er tun sollte. Der zuerst geschriebene Test ist die einzige Gelegenheit, eine Schnittstelle unvoreingenommen zu gestalten: Du stehst noch in der Rolle der Nutzerin, nicht der Autorin. Das Ergebnis sind APIs, die von außen lesbar sind, statt von innen.

Der zweite Effekt ist psychologisch: Ein Test, der zuerst rot ist, beweist, dass er überhaupt etwas prüft. Ein Test, der von Anfang an grün ist, ist häufig ein Test, der nichts fängt.

Die drei Regeln des Testens

Nicht alle Tests sind gleich. Die Testpyramide ordnet ein, worin man investieren sollte:

• Unit-Tests prüfen eine Einheit im isolation – schnell, zahlreich, die Basis der Pyramide.
• Integrationstests prüfen das Zusammenspiel mit echter Infrastruktur: Datenbank, Dateisystem, HTTP.
• End-to-End-Tests prüfen ganze Nutzerflüsse – langsam, teuer, daher sparsam an der Spitze.

Was TDD nicht ist

TDD ersetzt keine Code-Reviews, keine Integrationstests gegen echte Systeme und keine explorativen Tests. Es ist auch kein Dogma: Bei explorativem Prototyping – Spike-and-Solution – darf man erst bauen und später nachtesten. Aber: Der Produktionscode, der aus dem Spike hervorgeht, entsteht dann wieder testgetrieben.

Der Einstieg ist kleiner als gedacht

Niemand muss ein ganzes Projekt testgetrieben umstellen. Der pragmatische Einstieg: Nimm die nächste Funktion, die du schreiben willst, und schreibe zuerst den Test. Dann die zweite. Der Zyklus wird schnell zur Gewohnheit – und die Frage „Wo fange ich an?“ beantwortet sich von selbst: Immer beim nächsten roten Test.

Fazit

Testgetriebene Entwicklung ist ein Disziplin-System: kurze Zyklen, immer grüner Hauptzweig, Design von außen nach innen. Der Aufwand pro Feature steigt minimal – der Aufwand für spätere Änderungen sinkt drastisch. In Projekten, die Jahre leben, ist das die einzige Rechnung, die aufgeht.