Aufgabe 09 - Die Pyramide fürs Projekt

Aufgabe 09 - Die Pyramide fürs Projekt

Worum geht es?

Sie wenden die Testpyramide auf Ihr Jahresprojekt an: den Ist-Zustand vermessen, Lücken nach Risiko finden, gezielt auffüllen und die Datenzugriffsschicht mit Test-Doubles isolieren. Ziel ist nicht möglichst viel Test, sondern möglichst viel Sicherheit pro investierter Minute (siehe Kapitel Teststrategien I).

Was Sie dafür brauchen

• Kapitel Teststrategien I (Testebenen, Pyramide, Test-Doubles/Mocking, Testdaten).
• Ihr Jahresprojekt nach mindestens einem Sprint; der Testrunner des Projekts.

Welche Kompetenzen Sie erwerben und zeigen

• Sie ordnen vorhandene Tests den Ebenen zu und beurteilen die Form Ihrer realen Pyramide.
• Sie isolieren einen Service mit Test-Doubles und begründen die Grenzen dieser Isolation.
• Sie füllen Testlücken auf der jeweils angemessenen Ebene statt alles auf E2E zu schieben.

Pädagogische Einordnung

• Reproduktion: Tests den Ebenen zuordnen und die Pyramide zeichnen (Teil A).
• Reorganisation und Transfer: Services mit Doubles isolieren und Lücken gezielt auffüllen (Teile B und C).
• Reflexion, Problemlösung und Urteilsbildung: Stub und Mock unterscheiden, Testdaten entdoppeln und Coverage bewerten (Teil D).

Arbeitsaufträge

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

Teil A - Inventur

1. Listen Sie alle vorhandenen Tests Ihres Projekts und ordnen Sie jeden einer Ebene zu (Unit / Integration / E2E). Zeichnen Sie Ihre tatsächliche Pyramide. Ist sie überhaupt eine? (Eistüte, Eiszapfen oder Pilz sind häufige Diagnosen.)
2. Identifizieren Sie die drei riskantesten ungetesteten Stellen. Kriterium: Was tut bei einem Fehler am meisten weh?

Teil B - Isolieren mit Doubles

1. Wählen Sie einen Service mit Repository-Abhängigkeit und schreiben Sie Unit-Tests mit einem Test-Double für das Repository: Erfolgsfall, Fehlerfall (“nicht gefunden”), Randfall - alles ohne laufende Datenbank.
2. Messen Sie: Wie schnell laufen diese Tests verglichen mit den Integrationstests gegen SQLite? Notieren Sie die Zahlen; sie begründen die Pyramidenform.
3. Grenze des Doubles: Nennen Sie einen Fehlertyp in Ihrem Projekt, den der isolierte Test prinzipiell nicht finden kann (etwa falsches SQL), und welche Ebene ihn stattdessen fängt.

Teil C - Auffüllen

Schreiben Sie für die drei Risikostellen aus Teil A die fehlenden Tests auf der jeweils angemessenen Ebene (nicht alles auf E2E schieben). Jeder neue Test bekommt einen Satz Begründung im Commit.

Teil D - Expertenteil: Stub oder Mock, Testdaten und Coverage

1. Schreiben Sie einen Ihrer isolierten Tests aus Teil B in zwei Varianten: einmal mit einem Stub (liefert feste Antworten, geprüft wird der Endzustand) und einmal mit einem Mock (geprüft wird, dass eine bestimmte Repository-Methode mit bestimmten Argumenten aufgerufen wurde). Begründen Sie in zwei Sätzen, welche Variante hier die passendere ist und warum.
2. Bekämpfen Sie doppelte Testdaten: Bauen Sie einen kleinen Test-Data-Builder (eine Fabrik für gültige Beispielobjekte mit überschreibbaren Feldern), sodass jeder Test nur noch die für ihn relevanten Abweichungen angibt. Ziehen Sie mindestens zwei bestehende Tests darauf um.
3. Messen Sie die Testabdeckung (Coverage) einmal und beurteilen Sie in drei Sätzen: An welcher Stelle täuscht eine hohe Zahl Sicherheit vor, die nicht existiert, und warum ist Coverage ein Hinweis, aber kein Ziel?

Wissenscheck

1. Warum ist die Pyramidenform wirtschaftlich begründet und nicht bloß Konvention?
2. Was ist die typische Fehlform “Eistüte”, und woran erkennt man sie?
3. Was unterscheidet einen Stub von einem Mock?
4. Welchen Fehlertyp kann ein isolierter Unit-Test grundsätzlich nicht finden?
5. Warum ist eine hohe Coverage-Zahl kein Beweis für eine gute Testsuite?

Abgabe

Das Pyramiden-Diagramm (vorher/nachher), die neuen Tests als Merge Request mit Review, die Zeitmessung aus Teil B, die Stub/Mock-Varianten, der Test-Data-Builder und die Coverage-Bewertung.