Alle Tabs der Lerneinheit (Erklärung · Interaktiv verstehen · Praxis-Übung · Klausur-Quiz) als durchgehender Text. Ideal zum Wiederholen vor der Klausur, und für Suchmaschinen wie Google, Bing und KI-Suche (ChatGPT, Perplexity).
Erklärung
Kent Beck 1999: "Tests zuerst schreiben, dann Code." Was widersinnig klingt, hat die Art revolutioniert, wie viele Top-Entwickler Software bauen.
Die Idee in einem Satz
TDD: Entwickle Code, indem du ZUERST einen fehlschlagenden Test schreibst, dann gerade so viel Code, dass der Test grün wird, dann refactorst.
Der TDD-Zyklus: Red-Green-Refactor
Der Herzschlag von TDD, drei Phasen in einer Schleife:
┌──── 🔴 RED ────┐
│ │
│ 1. Schreibe einen│
│ fehlschlagenden │
│ Test │
│ │
└──────────────────┘
↓
┌──── 🟢 GREEN ────┐
│ │
│ 2. Minimal-Code, │
│ damit Test grün │
│ wird │
│ │
└──────────────────┘
↓
┌──── 🔵 REFACTOR ─┐
│ │
│ 3. Code verbessern│
│, Tests müssen │
│ grün bleiben │
│ │
└──────────────────┘
↓
(zurück zu RED)
Beispiel: TDD für eine Funktion addiere(a, b)
Zyklus 1
🔴 RED: Test schreiben
@Test
void addiere_zwei_positive_zahlen() {
assertEquals(5, Rechner.addiere(2, 3));
}
→ Test schlägt fehl: Rechner existiert nicht / addiere existiert nicht.
🟢 GREEN: Minimal-Code
public class Rechner {
public static int addiere(int a, int b) {
return 5; // Hard-coded, reicht für DIESEN Test!
}
}
→ Test grün ✓ (auch wenn der Code lächerlich aussieht).
Zyklus 2
🔴 RED: Nächster Test
@Test
void addiere_andere_zahlen() {
assertEquals(7, Rechner.addiere(3, 4));
}
→ Schlägt fehl: addiere(3, 4) gibt 5 zurück, nicht 7.
🟢 GREEN: Code anpassen
public static int addiere(int a, int b) {
return a + b; // Jetzt allgemein
}
→ Beide Tests grün ✓.
Zyklus 3
🔴 RED: Edge-Case
@Test
void addiere_negative_zahlen() {
assertEquals(-1, Rechner.addiere(-3, 2));
}
→ Schlägt fehl? Nein, geht direkt durch (a + b funktioniert für negative auch). → Wir wussten es jetzt: Code ist auch für diesen Fall korrekt.
🔵 REFACTOR
Code aufräumen, Tests müssen grün bleiben. In diesem trivialen Beispiel: nichts zu refactorn.
Die 3 Gesetze von TDD (Robert C. Martin)
- Du darfst keinen Produktions-Code schreiben, ohne vorher einen fehlschlagenden Test zu haben.
- Du darfst nicht mehr Test schreiben, als nötig ist, um fehlzuschlagen (auch Compile-Fehler zählt).
- Du darfst nicht mehr Produktions-Code schreiben, als nötig ist, um den aktuellen fehlschlagenden Test bestehen zu lassen.
Diese 3 Gesetze sind streng, viele Entwickler praktizieren TDD entspannter.
Vorteile von TDD
| Vorteil | Erklärung |
|---|---|
| Test-Coverage automatisch hoch | Jeder Code wurde durch Tests getrieben, keine ungetesteten Pfade |
| Refactoring sicher | Existierende Tests fangen Regressionen ab |
| Bessere Design-Entscheidungen | Code muss testbar sein → automatisch lose gekoppelt |
| Schnelles Feedback | Bugs werden sofort entdeckt, nicht erst im Test-Lauf |
| Doku als Nebenprodukt | Tests beschreiben, was der Code tut |
| Weniger Bug-Reports | Weil Edge-Cases aktiv durchdacht werden |
Nachteile / Häufige Kritikpunkte
| Nachteil | Erklärung |
|---|---|
| Lernkurve | Anfänger brauchen 3-6 Monate, bis TDD natürlich fließt |
| Initial-Geschwindigkeit langsam | Tests + Refactor kosten Zeit am Anfang |
| Geht nicht überall | UI-Tests, externe APIs schwer zu TDD'en |
| "Tests werden zu Specs" | Wenn man Tests zu früh schreibt, prägt das den Code zu sehr |
| Über-Engineering | Manche schreiben zu viele Tests, brauchen ewig für simple Features |
Wann TDD verwenden?
Geeignet für:
- Geschäftslogik mit komplexen Regeln
- Algorithmen mit klaren Inputs/Outputs
- Code-Bereiche mit hohem Risiko
- Refactoring bestehenden Codes (Tests zuerst, dann ändern)
Weniger geeignet für:
- Prototyping / Spike-Code (wird oft weggeworfen)
- UI/Frontend (E2E-Tests besser)
- Exploratives Coding ohne klare Anforderungen
TDD vs. BDD vs. ATDD
| Ansatz | Fokus | Beispiel |
|---|---|---|
| TDD | Code-Verhalten | assertEquals(5, addiere(2, 3)) |
| BDD | Geschäfts-Verhalten in Sprache | Given X, When Y, Then Z |
| ATDD | Akzeptanz-Kriterien | Tests aus Sicht des Kunden |
Klausur-Faustregeln
1. Red-Green-Refactor: Test schreiben (rot), Code schreiben (grün), Code verbessern (refactor).
2. Zuerst Test, dann Code. Kein Produktions-Code ohne fehlschlagenden Test.
3. Minimal-Code: so wenig wie nötig, damit der Test grün wird.
4. Refactor-Phase: Code aufräumen, aber Tests müssen grün bleiben.
5. Erfinder: Kent Beck (1999).
6. TDD ≠ einfach Tests schreiben. TDD = Tests ZUERST schreiben.
Häufige Stolpersteine
1. Test NACH dem Code schreiben. Das ist NICHT TDD. Das ist "Test-Validated Development". Beides hat Wert, aber TDD garantiert Design-Effekte, die Post-hoc-Tests nicht haben.
2. Refactor-Phase weglassen. Häufiger Fehler: Test grün → "fertig". Aber gerade die Refactor-Phase verbessert den Code. Ohne sie häuft sich technische Schuld.
3. Zu große Test-Schritte. Wenn ein Test 10 Zeilen Code braucht, um grün zu werden, ist der Schritt zu groß. Lieber kleiner Schritte (Baby Steps).
4. TDD überall erzwingen. TDD ist ein Werkzeug, kein Religion. Für simple CRUD-Operationen oder UI-Code ist TDD oft Overhead.
5. Tests zu eng an Implementierung koppeln. Wenn ein Refactor 20 Tests bricht, sind die Tests an der falschen Stelle, sie testen Implementierung, nicht Verhalten.
Interaktiv verstehen
TDD-Zyklus durchspielen
Erlebe den Red-Green-Refactor-Zyklus an einem konkreten Beispiel. Klick durch die Phasen.
Interaktive Visualisierung
Interaktive Komponente: probiere sie im Topic-Player oben aus.
Klausur-Tipp: Wenn die Frage lautet "Beschreibe TDD", IMMER 3 Punkte nennen: 1) Test ZUERST schreiben (red), 2) Minimal-Code für grün, 3) Refactoring. Plus den Erfinder (Kent Beck 1999), das gibt Extrapunkte.
Praxis-Übung
TDD, Praxis-Übung
6 Aufgaben zum Zyklus, den 3 Gesetzen und typischen Anti-Patterns.
Klausurfragen mit Lösungen (6)
- F1.In welcher Reihenfolge laufen die 3 Phasen des TDD-Zyklus ab?
Antwort: Red → Green → Refactor
Erklärung: TDD-Zyklus: 1) RED, fehlschlagenden Test schreiben, 2) GREEN, Minimal-Code, damit Test grün wird, 3) REFACTOR, Code verbessern, Tests bleiben grün. Dann zurück zu Red für nächstes Feature. Wichtig: REFACTOR-Phase NICHT überspringen, sonst sammelt sich technische Schuld an.
- F2.Wann wird der Test in TDD geschrieben?
Antwort: Vor dem Code, treibt das Design
Erklärung: Der Test wird ZUERST geschrieben, das ist der Kern von TDD. Erst dann wird der Produktions-Code geschrieben. Test-VOR-Code ist der entscheidende Unterschied zu 'normalem Testen'. Das erzeugt automatisch lose gekoppelten, testbaren Code als Nebeneffekt.
- F3.Ordne die TDD-Phasen ihren Beschreibungen zu.
Zuordnungen:
- Red → Schreibe einen fehlschlagenden Test
- Green → Minimal-Code, damit Test grün wird
- Refactor → Code aufräumen, Tests bleiben grün
- (nächster Zyklus) → Wieder Red mit neuem Test
Erklärung: Die 3 TDD-Phasen plus die Iteration: Red (fehlschlagender Test), Green (Code dafür), Refactor (Code-Qualität verbessern). Danach wieder Red für das nächste Feature. Dieser Mini-Zyklus dauert oft nur Minuten, Baby Steps.
Typ: Zuordnung
- F4.Wer hat TDD popularisiert?
Antwort: Kent Beck
Erklärung: Kent Beck popularisierte TDD 1999 mit seinem Buch 'Test-Driven Development: By Example'. Beck ist auch Mitbegründer von Extreme Programming (XP) und Co-Autor des Agile Manifests. Robert C. Martin formulierte später die '3 Gesetze von TDD'.
- F5.In der Green-Phase darf der Code auch hard-coded sein, Hauptsache, der Test ist grün.
Antwort: Wahr
Erklärung: RICHTIG! In der Green-Phase ist 'kleinster Code, der den Test grün macht' das Ziel, auch wenn das hard-coded ist (z.B. `return 5`). Im NÄCHSTEN Zyklus zwingt ein neuer Test dazu, den Code zu verallgemeinern. Dieses kontraintuitive Vorgehen verhindert Über-Engineering und macht TDD-Zyklen klein.
Typ: Wahr/Falsch
- F6.Welcher der folgenden ist KEIN typischer Vorteil von TDD?
Antwort: Code wird zu 100 % bug-frei
Erklärung: TDD garantiert KEINE 100 % Bug-Freiheit, Bugs können trotzdem entstehen (z.B. wenn der Test selbst falsch ist, oder bei Edge-Cases, die niemand bedachte). Was TDD wirklich liefert: höhere Coverage, lose gekoppeltes Design, sicheres Refactoring, schnelleres Feedback. Bug-Freiheit ist Wunschdenken, auch mit TDD braucht es Code-Reviews + Integrations-/E2E-Tests.
Klausur-Quiz
TDD, Klausur-Quiz
6 typische Klausurfragen.
Klausurfragen mit Lösungen (6)
- F1.Was bedeutet die Refactor-Phase im TDD-Zyklus?
Antwort: Code aufräumen + verbessern, aber Tests müssen grün bleiben
Erklärung: Refactor-Phase: Code-Qualität verbessern (z.B. Variablen umbenennen, Methoden extrahieren, Duplikate entfernen) OHNE Verhalten zu ändern. Tests sind die Sicherheits-Netz: solange sie grün bleiben, hat das Refactoring nichts kaputt gemacht. Wichtig: Refactor NICHT überspringen, sonst wird der Code mit der Zeit schlechter.
- F2.Was passiert in TDD vor dem Produktions-Code?
Antwort: Es wird ein Test geschrieben, der fehlschlagen muss
Erklärung: Der RED-Schritt: Test ZUERST. Der Test muss INITIAL FEHLSCHLAGEN, sonst weiß man nicht, ob er überhaupt etwas prüft. Erst danach Produktions-Code schreiben (Green). Dieses TEST-FIRST-Prinzip ist der entscheidende Unterschied zu 'normalem Testen', wo Tests oft erst nach dem Code geschrieben werden.
- F3.Der TDD-Zyklus heißt {{1}}-{{2}}-{{3}}. Er wurde von {{4}} popularisiert. In der ersten Phase muss der Test {{5}} (fehlschlagen oder bestehen?).
Lösungen pro Lücke:
- {{1}}: Red / red / Rot
- {{2}}: Green / green / Grün
- {{3}}: Refactor / refactor
- {{4}}: Kent Beck / Beck
- {{5}}: fehlschlagen
Erklärung: Red-Green-Refactor von Kent Beck (1999). Der Test in der Red-Phase MUSS fehlschlagen, sonst hat man keine Bestätigung, dass der Test wirklich was testet. Erst wenn er rot ist, kann man sicher sein, dass die spätere Grün-Phase einen Effekt hatte.
Typ: Lückentext
- F4.Bringe die TDD-Schritte für die Funktion istGerade(n) in die richtige Reihenfolge.
Richtige Reihenfolge:
- Test `assertTrue(istGerade(4))` schreiben (schlägt fehl, Funktion existiert noch nicht)
- Funktion `istGerade(n) { return n % 2 == 0; }` schreiben
- Refactoring: Variablen umbenennen, Tests bleiben grün
- Nächsten Test `assertFalse(istGerade(5))` schreiben
Erklärung: TDD-Reihenfolge: 1) Test schreiben, schlägt fehl (Red), 2) Funktion schreiben, Test grün (Green), 3) Code aufräumen (Refactor), 4) Nächster Test (zurück zu Red). So entsteht der Code Schritt für Schritt, gefahren von Tests.
Typ: Reihenfolge
- F5.In der GREEN-Phase ist es laut TDD ERLAUBT:
Antwort: Code zu schreiben, der hard-coded auf den Test passt
Erklärung: In Green ist das Ziel: GERADE SO VIEL CODE, dass der aktuelle Test grün wird, auch wenn das hard-coded ist. Beispiel: erster Test verlangt `addiere(2,3) == 5`, dann ist `return 5` völlig OK. Beim ZWEITEN Test (`addiere(3,4) == 7`) zwingt die Realität dazu, den Code zu verallgemeinern. Diese 'Baby Steps' verhindern Über-Engineering.
- F6.TDD garantiert, dass keine Bugs im Produktions-Code auftreten.
Antwort: Falsch
Erklärung: FALSCH. TDD reduziert Bugs DEUTLICH, aber garantiert KEINE Bug-Freiheit. Bugs entstehen z.B. wenn: 1) der Test selbst falsch ist (Bug im Test), 2) Edge-Cases nicht bedacht wurden, 3) Integration zwischen Komponenten falsch (nicht von Unit-Tests abgedeckt). TDD muss kombiniert werden mit Code-Reviews, Integration-Tests, manuellen Tests. Allheilmittel-Denken ist immer falsch.
Typ: Wahr/Falsch
