Aufgabe 10 - TDD-Kata

Aufgabe 10 - TDD-Kata

Worum geht es?

Sie probieren testgetriebene Entwicklung selbst aus: erst der rote Test, dann der Code, dann das Aufräumen, streng nach Regeln, damit der Rhythmus sitzt. Zum Abschluss heben Sie denselben Gedanken mit ATDD auf die Ebene eines ganzen Features (siehe Kapitel Teststrategien II).

Was Sie dafür brauchen

• Kapitel Teststrategien II (Red-Green-Refactor, ATDD und die doppelte Schleife).
• Ein TypeScript-Projekt mit Testrunner; Paararbeit (Fahrer/Navigator, Wechsel alle zehn Minuten).

Welche Kompetenzen Sie erwerben und zeigen

• Sie durchlaufen den TDD-Zyklus diszipliniert und in kleinsten Schritten.
• Sie belegen den Prozess über eine saubere Commit-Historie.
• Sie formulieren einen Akzeptanztest und treiben ein Feature in der doppelten Schleife.

Pädagogische Einordnung

• Reproduktion: die Red-Green-Refactor-Regeln befolgen (Teile A und B).
• Reorganisation und Transfer: ein Verhalten Schritt für Schritt entstehen lassen (Teil B).
• Reflexion, Problemlösung und Urteilsbildung: den Nutzen ehrlich bewerten und ATDD anwenden (Teile C und D).

Die Kata: Notenrechner der HTL

Zu bauen (aber nur testgetrieben): computeReportGrade(results: ExamResult[]): Grade mit den Regeln: gewichteter Schnitt (Tests zählen doppelt), Notenschlüssel 91/81/66/50, “Nicht genügend” wenn der letzte Test negativ war (unabhängig vom Schnitt), Exception bei leerer Liste oder Punkten außerhalb 0-100.

Arbeitsaufträge

Die Übung ist auf etwa zwei Stunden ausgelegt. Teil D ist der Expertenteil.

Teil A - Die strengen Regeln

Es gilt für die gesamte Kata:

1. Kein Produktionscode ohne vorher fehlschlagenden Test.
2. Nur so viel Produktionscode, dass der aktuelle Test grün wird, auch wenn es “dumm” aussieht (die hartkodierte erste Rückgabe ist erlaubt und erwünscht).
3. Refactoring nur bei grünen Tests.
4. Committen Sie nach jedem Zyklus mit Präfix red:/green:/refactor: - die Historie ist Ihr Nachweis.

Teil B - Durchführung

Arbeiten Sie die Regeln in selbst gewählter Reihenfolge ab, aber beginnen Sie mit dem einfachsten Fall. Erwartung: 10 bis 15 Zyklen. Wenn ein Test auf Anhieb grün ist, halten Sie inne: Entweder war der Schritt zu groß oder der Test prüft nichts Neues.

Teil C - Retrospektive

Beantworten Sie ehrlich (je zwei bis vier Sätze): An welcher Stelle hat ein Test einen Fehler gefangen, den Sie ohne TDD eingebaut hätten? Wo fühlte sich der Zwang künstlich an? Hat das Design am Ende anders ausgesehen als vorab gedacht? Würden Sie TDD im Jahresprojekt einsetzen - wofür ja, wofür nein?

Teil D - Expertenteil: Von TDD zu ATDD

1. Nehmen Sie eine neue Anforderung an den Notenrechner (etwa: “eine Frühwarnung, wenn mehr als die Hälfte der Einzelnoten schlechter als Befriedigend ist”). Formulieren Sie sie zuerst als Akzeptanztest im Given-When-Then-Schema, aus Nutzersicht, bevor eine Zeile Implementierung entsteht.
2. Treiben Sie das Feature in der doppelten Schleife: der Akzeptanztest ist die äußere Schleife (rot), die Unit-Tests im Red-Green-Refactor die innere. Bleiben Sie in der inneren Schleife, bis der Akzeptanztest grün wird. Die Commit-Historie soll beide Schleifen erkennbar machen.
3. Beurteilen Sie in drei Sätzen: Warum ist ein ausführbarer Akzeptanztest ein maschinell prüfbarer Vertrag, und warum hat sich ATDD gerade beim agentic coding als Steuerungswerkzeug durchgesetzt?

Wissenscheck

1. Warum muss der erste Test einer Kata fehlschlagen, bevor Code entsteht?
2. Warum schreibt man in Green bewusst den einfachsten, notfalls “dummen” Code?
3. Wann hilft TDD besonders, und wann bremst es eher?
4. Was ist der Unterschied zwischen TDD und ATDD?
5. Was beschreibt die “doppelte Schleife”, und welche Frage beantwortet jede der beiden Schleifen?

Abgabe

Das Git-Repository (die Commit-Historie ist die halbe Note), die Retrospektive und das per ATDD entwickelte Feature mit erkennbarer doppelter Schleife.