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).
Teil 1·Erklärung
Diese Lerneinheit wurde für typische Bachelor-Klausuren konzipiert. So prüfen wir · Fehler entdeckt? Melde ihn uns oder markiere die fragliche Stelle direkt im Text oben.
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).
Kent Beck 1999: "Tests zuerst schreiben, dann Code." Was widersinnig klingt, hat die Art revolutioniert, wie viele Top-Entwickler Software bauen.
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.
Anmelden, um den Fortschritt zu speichern.
Nächster Schritt
Aktives Abrufen festigt Wissen schneller als nochmal lesen.
Kent Beck 1999: "Tests zuerst schreiben, dann Code." Was widersinnig klingt, hat die Art revolutioniert, wie viele Top-Entwickler Software bauen.
TDD: Entwickle Code, indem du ZUERST einen fehlschlagenden Test schreibst, dann gerade so viel Code, dass der Test grün wird, dann refactorst.
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)
addiere(a, b)🔴 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).
🔴 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 ✓.
🔴 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.
Diese 3 Gesetze sind streng — viele Entwickler praktizieren TDD entspannter.
| 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 |
| 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 |
Geeignet für:
Weniger geeignet für:
| 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 |
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.
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.
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.
6 Aufgaben zum Zyklus, den 3 Gesetzen und typischen Anti-Patterns.
Klausurfragen mit Lösungen (6)
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.
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.
Zuordnungen:
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
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'.
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
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.
6 typische Klausurfragen.
Klausurfragen mit Lösungen (6)
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.
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.
Lösungen pro Lücke:
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
Richtige Reihenfolge:
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
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.
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