Aufgabe 14 - Jahresprojekt Sprint 4 - TDD, End-to-End und Teststrategie

Lernziele

Du entwickelst eine Funktion testgetrieben im Rhythmus Red-Green-Refactor und machst den Rhythmus in der Commit-Historie sichtbar.
Du schreibst für dein Projekt eine Teststrategie, die Ebene, Werkzeug und Umfang je Systemteil aus dem Risiko begründet.
Du sicherst den wichtigsten Flow deines Projekts mit einem End-to-End-Test ab, der ohne feste Wartezeiten stabil läuft.
Du verankerst Tests im Prozess: Merge-Blocker, „Bug zuerst als Test“ und Coverage als Indikator.

Ausgangslage

Zweite Woche von Sprint 4. Kapitel 20 schließt die Teststrategien ab: TDD (erst der rote Test, dann der Code, dann das Aufräumen), ATDD mit der doppelten Schleife, End-to-End-Tests für die wenigen wichtigsten Flows, flaky Tests und die dokumentierte Teststrategie. Kapitel 21 verlangt für das Jahresprojekt eine gelebte Teststrategie, die automatisch in der Pipeline läuft, und dass die wichtigsten Flows End-to-End getestet sind. Heute legt ihr dafür den Grundstein.

Die Kata: Dateinamen für Uploads. Zu bauen, aber nur testgetrieben, ist cleanFileName(name: string): string. Die Regeln:

Kleinbuchstaben: "Foto.JPG" wird zu "foto.jpg".
Leerzeichen werden zu Bindestrichen: "mein foto.png" wird zu "mein-foto.png".
Klammern verschwinden: "foto (1).png" wird zu "foto-1.png".
Ein leerer Name oder ein Name nur aus Leerzeichen ist ein Fehler (Exception).

Die strengen Regeln der Kata:

Kein Produktionscode ohne vorher fehlschlagenden Test.
Nur so viel Code, dass der aktuelle Test grün wird, auch wenn er „dumm“ aussieht.
Refactoring nur bei grünen Tests.
Commit nach jedem Schritt mit dem Präfix red:, green: oder refactor:.

Dafür brauchst du:

Kapitel 20 Teststrategien II (Red-Green-Refactor, ATDD und doppelte Schleife, End-to-End-Tests und Flows, flaky Tests, Qualitätssicherung im Prozess, dokumentierte Teststrategie).
Kapitel 19 für Ebenen und Werkzeuge; Vitest und Playwright (npm install --save-dev @playwright/test, npx playwright install chromium). Ist der Browser-Download im Schulnetz blockiert, verwende den installierten Chrome mit use: { channel: "chrome" } in playwright.config.ts.
Eure Flows aus dem Use-Case-Diagramm (Aufgabe 04) und eure Ist-Pyramide (Aufgabe 13).

Allgemein

Projektordner anlegen siehe https://qiz.at/projektordner

Lies vorher kurz https://qiz.at/assignmentsabgabe durch.
Nur vollständige Abgaben (siehe https://qiz.at/rules) können positiv bewertet werden.
Abgabe- und Testdetails siehe https://qiz.at/assignmentsabgabe
Abgegeben wird das Git-Repository der Kata (die Commit-Historie ist Teil der Abgabe) mit einer README.md und den Links auf Issues, Merge Requests, docs/teststrategie.md und die End-to-End-Tests im Jahresprojekt-Repository. Bezeichner und Kommentare im Code sind Englisch.
Wer was beigetragen hat, zeigen Board, Merge Requests und /spend-Einträge (Kapitel 07).

Wesentlich_überwiegend

Aufgabe

Kata: Baue cleanFileName streng nach den vier Regeln, beginnend mit dem einfachsten Fall. Jede Regel bekommt mindestens einen eigenen Zyklus, am Ende steht ein Refactor-Schritt bei grünen Tests. Die Historie zeigt für jeden Zyklus red:, green: und, wo nötig, refactor:.
Erkläre im README.md in je ein bis zwei Sätzen, warum der erste Test fehlschlagen muss, bevor Code entsteht, und an welcher Stelle der Kata sich der Zwang künstlich angefühlt hat.

Tipp: Wenn ein Test auf Anhieb grün ist, halte inne: Entweder war der Schritt zu groß, oder der Test prüft nichts Neues. In TypeScript zählt ein Kompilierfehler „Funktion existiert nicht“ als rot.

Bewertungskriterien

Vollständig, wenn:

jede Regel einen eigenen Test hat, alle Tests grün sind und die Historie für jeden Zyklus die Präfixe in der richtigen Abfolge zeigt, beginnend mit einem roten Test,
mindestens ein Refactor-Commit bei grünen Tests erkennbar ist,
beide Erklärungen im README.md stehen und eine konkrete Stelle der eigenen Historie nennen.

Abgabe

Wie unter Allgemein.

Wesentlich_vollständig

Für alle, die in der Einheit mit den Schritten oben fertig sind bzw. optional (= freiwillig), wenn du in der Einheit nicht fertig wirst.

Aufgabe

Erweitere (siehe Erweitern in https://qiz.at/rules) den vollständigen Teil der vorherigen Stufe dieser Datei (ändere oder lösche nur, was für diese Aufgabe unbedingt notwendig ist):

Teststrategie: Schreibt docs/teststrategie.md für euer Projekt mit drei Teilen:
- eine Tabelle mit einer Zeile je Systemteil und den Spalten Systemteil, Risiko (aus Sicht der Nutzerinnen und Nutzer), Ebene, Werkzeug, Umfang,
- einen Abschnitt Bewusste Lücken (mindestens zwei, keine in einem Teil mit hohem Risiko),
- einen Abschnitt Prozess: was einen Merge blockiert, was bei einem gefundenen Fehler zuerst entsteht und warum, welche Rolle die Coverage spielt.
End-to-End-Test: Richtet Playwright im Projekt ein und automatisiert den wichtigsten Flow eures Projekts (Happy Path) in e2e/. Der Test arbeitet mit Selektoren, die auf das zielen, was eine Nutzerin sieht (getByRole, getByLabel, getByText), und ohne feste Wartezeit. Lasst ihn fünfmal hintereinander laufen (npx playwright test --repeat-each=5).
Tragt den Namen des Tests in der Zeile des Systemteils in der Teststrategie ein.

Tipp: Formuliere Risiken aus Nutzersicht („Wenn die Buchung doppelt durchgeht, steht eine Band vor einem besetzten Raum“), nicht aus der Technik. Playwright wartet von sich aus auf Elemente, wenn du auf eine Bedingung prüfst statt auf eine Zeit.

Bewertungskriterien

Vollständig, wenn:

docs/teststrategie.md alle Systemteile mit allen fünf Spalten enthält, die Risiken aus Nutzersicht formuliert und nicht alle gleich hoch sind und die Ebenen zur Pyramide passen,
mindestens zwei begründete Lücken und ein Prozess mit Merge-Blocker, „Fehler zuerst als Test“ samt Begründung und Coverage als Indikator dokumentiert sind,
der End-to-End-Test des wichtigsten Flows ohne waitForTimeout auskommt und in fünf Läufen hintereinander grün bleibt,
der Test in der Teststrategie seinem Systemteil zugeordnet ist.

Abgabe

Wie unter Allgemein.

PlusPlus Aufgabe

Für alle, die in der Einheit mit den Schritten oben fertig sind bzw. optional (= freiwillig), wenn du in der Einheit nicht fertig wirst.

Aufgabe

Erweitere (siehe Erweitern in https://qiz.at/rules) den vollständigen Teil der vorherigen Stufe dieser Datei (ändere oder lösche nur, was für diese Aufgabe unbedingt notwendig ist):

Automatisiert einen Fehler-Flow (die wichtigste Ausnahme des Flows, zum Beispiel eine abgelehnte Eingabe) und begründet in der Teststrategie, wo ihr die übrigen Fehlerfälle günstiger abfangt.
Lasst die End-to-End-Tests in der Pipeline laufen, sodass ein roter Test den Merge blockiert, und verlinkt einen grünen Lauf.
Ergänzt in der Definition of Done eine Zeile „Bug zuerst als Test“ und wendet sie auf einen Fehler aus Sprint 4 an (roter Test im Commit vor der Behebung).

Tipp: Das Playwright-Image für die Pipeline muss zur installierten Playwright-Version passen (siehe https://playwright.dev/docs/docker). Retries in der Konfiguration verstecken flaky Verhalten nur, sie beheben es nicht.

Bewertungskriterien

Vollständig, wenn:

der Fehler-Flow grün ist und die Teststrategie die günstigere Ebene für die übrigen Fehlerfälle nennt,
die Pipeline die End-to-End-Tests ausführt, ein roter Test den Merge blockiert und ein grüner Lauf verlinkt ist,
die DoD-Zeile ergänzt ist und die Historie einen roten Test vor der Behebung eines echten Fehlers zeigt.

Abgabe

Wie unter Allgemein.

MandalorianPlus Aufgabe

Für alle, die in der Einheit mit den Schritten oben fertig sind bzw. optional (= freiwillig), wenn du in der Einheit nicht fertig wirst.

Aufgabe

Erweitere (siehe Erweitern in https://qiz.at/rules) den vollständigen Teil der vorherigen Stufe dieser Datei (ändere oder lösche nur, was für diese Aufgabe unbedingt notwendig ist):

Entwickle eine Story aus Sprint 4 in der doppelten Schleife: zuerst ein Akzeptanztest im Schema Given-When-Then aus Nutzersicht (Commit red(acceptance):), dann innere Unit-Zyklen mit red:/green:/refactor:, bis der Akzeptanztest grün ist (green(acceptance):). Halte vorher fest, welche Auslegungsfragen die Story offenlässt, und entscheide sie im Akzeptanztest.
Beurteile in drei Sätzen, warum ein ausführbarer Akzeptanztest ein maschinell prüfbarer Vertrag ist und warum er beim agentic coding als Steuerungswerkzeug dient.

Tipp: Ein Akzeptanztest ruft das Feature von außen auf, nicht eure Hilfsfunktionen. Grenzfälle der Story gehören in den Akzeptanztest.

Bewertungskriterien

Vollständig, wenn:

der Akzeptanztest vor der Implementierung rot in der Historie steht, innere Zyklen erkennbar sind und er am Ende grün ist,
die Auslegungsfragen im Test entschieden sind,
die Beurteilung beide Teile (Vertrag, Steuerungswerkzeug) mit einem Argument begründet.

Abgabe

Wie unter Allgemein.

Zeit dafür

Durchschnittlich bis Wesentlich_vollständig: ca. 70 min (5 min Board-Check, 20 min Kata, 20 min Teststrategie, 25 min End-to-End-Test)

Autoren

GAM

Lizenz

CC-BY-SA

Regeln

https://qiz.at/rules