--- name: testgetrieben-entwickeln description: Entwickelt fachliches Verhalten und Fehlerbehebungen in kleinen testgetriebenen Schritten und sichert jede betroffene Komponente sowie den übergreifenden Vertical Slice auf passenden Testebenen ab. Verwenden, wenn Codeverhalten, APIs, Persistenz, Integrationen, Deployment oder ein vollständiger Nutzerablauf implementiert oder geändert werden. --- # Testgetrieben entwickeln Behandle Tests als Teil jedes Tasks und des Vertical Slice, nicht als spätere Arbeitsphase. Beweise das gewünschte Verhalten mit der kleinsten stabilen Testebene und ergänze die Nachweise an allen betroffenen Komponenten und technischen Grenzen. ## Fachliche Grundlage - [Kent Beck – Test-Driven Development: By Example](https://www.pearson.com/en-us/subject-catalog/p/test-driven-development-by-example/P200000009421/9780321146533) ist die Referenz für den kurzen Zyklus aus fehlschlagendem Test, einfachster funktionierender Änderung und anschliessendem Refactoring. - [Jimmy Bogard – Vertical Slice Architecture](https://www.jimmybogard.com/vertical-slice-architecture/) beschreibt Funktionen als zusammenhängende Anwendungsfälle über technische Schichten hinweg. - [Ham Vocke – The Practical Test Pyramid](https://martinfowler.com/articles/practical-test-pyramid.html) erläutert schnelle Tests unterschiedlicher Granularität und wenige teure Ende-zu-Ende-Tests. Die ursprüngliche Testpyramide stammt von Mike Cohn. - [Playwright – Best Practices](https://playwright.dev/docs/best-practices) empfiehlt, im Browser sichtbares Nutzerverhalten statt Implementierungsdetails zu prüfen. ## Vertical-Slice-Tests und Komponententests - **Testgetrieben in Vertical Slices:** Entwickle eine fachliche Änderung in kleinen, überprüfbaren Slices. Ein fachlicher Test prüft die Business-Logik über alle dafür betroffenen Stacks hinweg, zum Beispiel von Oberfläche oder API über Anwendung und Domain bis zur Persistenz. So wird das fachliche Verhalten als zusammenhängender Ablauf nachgewiesen. - **Komponententests:** Ergänze eigenständige Tests, die die Funktionalität einer einzelnen betroffenen Komponente direkt prüfen. Sie zeigen, ob diese Komponente ihre eigene Verantwortung korrekt erfüllt. - **Zusammenspiel:** Der Vertical-Slice-Test und die Komponententests ersetzen einander nicht. Der eine prüft das fachliche Verhalten über die betroffenen Stacks, die anderen die lokalen Verantwortungen der Komponenten. - **DevSecOps und Security by Design:** Sicherheits- und Datenschutzprüfungen werden im selben Vertical Slice mitgeführt. Relevante Kontrollen, Rechte, Datenflüsse und Missbrauchsfälle erhalten eigene passende Nachweise und werden nicht erst nach der fachlichen Umsetzung ergänzt. ## Nichtziele - Nicht jede Klasse und nicht jede Methode isoliert testen. - Nicht jede technische Schicht mit demselben Test wiederholen. - Komponententests durch einen übergreifenden Test ersetzen. ## Komponentenweise Nachweise 1. Liste für den Task die betroffenen Komponenten und technischen Grenzen auf. Dazu können beispielsweise Quellcode, API, Datenbankmigration, Konfiguration, Secret-Fluss, Deployment oder Browser gehören. 2. Gib jeder betroffenen Komponente einen eigenen passenden Funktionsnachweis. Der Nachweis prüft die Verantwortung dieser Komponente direkt und wird nicht durch einen späteren End-to-End-Test ersetzt. 3. Wähle für jede Komponente die kleinste stabile Testebene, die ihr Risiko tatsächlich beweist. Verwende für technische Infrastruktur auch Validierung, Dry-Run, kontrollierten Wiederaufbau oder eine reproduzierbare manuelle Prüfung, wenn ein klassischer Test nicht passend ist. 4. Ergänze für jeden fachlichen Vertical Slice einen passenden übergreifenden Nachweis über die betroffenen Stacks. Er prüft das Business-Verhalten, sicherheits- und datenschutzrelevante Kontrollen und darf fehlende Komponentennachweise nicht verdecken. 5. Dokumentiere bei einer manuellen Prüfung den Ablauf, das erwartete Ergebnis und die Begründung, warum sie nicht sinnvoll automatisiert werden kann. ## Für jeden Task und Vertical Slice 1. Formuliere ein kleines beobachtbares Ergebnis und mindestens ein konkretes Beispiel in der bestätigten Fachsprache aus `docs/domain/DOMAIN.md`, sofern vorhanden. Verwende bei Bedarf `Gegeben – Wenn – Dann`. 2. Liste die betroffenen Komponenten und Grenzen auf und ordne jeder den eigenen Funktionsnachweis zu. 3. Schreibe oder ändere zuerst den jeweils passenden Test und führe ihn aus. Stelle sicher, dass er aus dem erwarteten Grund fehlschlägt, sofern es sich um neues oder geändertes Codeverhalten handelt. 4. Implementiere nur so viel, dass der Nachweis besteht. 5. Räume Code und Test auf, ohne das Verhalten zu ändern. Führe die relevanten Nachweise erneut aus. 6. Ergänze Tests an echten Systemgrenzen und höchstens wenige Tests für den vollständigen Nutzerweg. Wiederhole denselben fachlichen Fall nicht auf jeder technischen Schicht, aber lasse keine betroffene Komponente ohne eigenen Nachweis. 7. Leite relevante Berechtigungs-, Datenminimierungs-, Offenlegungs- und Missbrauchstests aus `sicherheit-und-datenschutz-pruefen` ab. 8. Führe vor Abschluss alle Nachweise des Tasks und die vereinbarte Projektprüfung aus. Fasse das Prüfergebnis im Task fachlich zusammen; kopiere keine langen Testprotokolle hinein. ## Passende Testebene wählen - **Fachregel oder Zustandsübergang:** schneller Unit-Test ohne Infrastruktur. - **Datenbank, HTTP-Vertrag, Dateisystem oder Warteschlange:** Integrationstest gegen eine realistische kontrollierte Grenze. - **Konfiguration, Deployment oder Infrastruktur:** Validierung, Plan-, Dry-Run- oder kontrollierter Wiederaufbau-Test gegen die echte Zielgrenze. - **Secret-Fluss oder Berechtigungsgrenze:** kontrollierter Integrations- oder Zugriffsnegativtest ohne echte Secret-Werte in Ausgabe oder Artefakten. - **Vertrag zu einem fremden System:** Vertragstest oder kontrollierter Stub; keine unkontrollierte produktive Abhängigkeit im Test. - **Vollständiger Webablauf:** wenige stabile Browsertests über sichtbare Rollen, Beschriftungen und Inhalte. - **Aussehen und responsive Wirkung:** Browserprüfung und bei stabilen Abnahmeansichten gezielter Screenshot-Vergleich. Visuelle Qualität lässt sich nicht allein durch TDD beweisen. - **Sicherheit, Datenschutz oder Leistung:** risikobezogene Prüfung ergänzen, wenn der Slice diese Eigenschaften berührt. Beweise jedes beobachtbare Risiko möglichst mit einem führenden Test. Ein API-Integrationstest darf beispielsweise HTTP-Vertrag und Datenbank gemeinsam abdecken. Ergänze einen separaten Test nur, wenn die zusätzliche Grenze ein eigenes Risiko trägt. Prüfe Fehler- und Leerzustände der Oberfläche meist mit kontrollierten Antworten; erzwinge dafür keinen echten Datenbankausfall im Browser. Verwende keine feste Prozentzahl für Testarten. Halte schnelle Tests zahlreich und teure, breite Tests gezielt. Teste keine privaten Methoden, CSS-Klassen oder interne Schichten nur deshalb, weil sie existieren. Mocke bevorzugt fremde oder langsame Grenzen, nicht die eigene Fachlogik. ## Fehler beheben Erzeuge vor der Korrektur nach Möglichkeit einen Test, der den Fehler reproduziert. Kann der Fehler nicht sinnvoll automatisiert werden, dokumentiere warum und wie die Korrektur stattdessen wiederholbar geprüft wurde. ## Ausnahmen Erzwinge keinen vorgeschalteten Test für reine Dokumentations-, Formatierungs- oder explorative Gestaltungsschritte ohne prüfbares Codeverhalten. Sobald aus einem Prototyp dauerhaftes Verhalten wird, sichere es vor der weiteren Ausgestaltung ab. ## Fertig, wenn - Akzeptanzkriterien und Tests dasselbe beobachtbare Verhalten beschreiben. - mindestens ein Test während der Entwicklung erwartbar fehlschlug. - relevante Fach-, Komponenten-, Integrations- und Nutzerweg-Risiken abgedeckt sind. - jede betroffene Komponente einen eigenen angemessenen Funktionsnachweis oder eine begründete reproduzierbare manuelle Prüfung besitzt. - alle vereinbarten Prüfungen erfolgreich sind. - Tests unabhängig, verständlich und nicht an unnötige Implementierungsdetails gekoppelt sind.