tdd

Überblick über den tdd skill

Der tdd skill ist eine fokussierte Anleitung für testgetriebene Entwicklung mit einem strikten Red-Green-Refactor-Zyklus – kein generischer Prompt nach dem Motto „schreib ein paar Tests“. Am meisten bringt er Entwicklerinnen und Entwicklern, die KI beim Bauen von Features oder beim Beheben von Bugs einsetzen wollen und dabei Tests an Verhalten über öffentliche Schnittstellen koppeln möchten statt an Implementierungsdetails.

Wofür der tdd skill gedacht ist

Nutze tdd for Test Driven Development, wenn das Modell:

• ein Feature in kleine vertikale Scheiben planen soll
• jeweils genau einen fehlschlagenden Test schreiben soll
• nur so viel Code implementieren soll, wie zum Bestehen nötig ist
• nach Grün sicher refaktorieren soll
• fragile Tests vermeiden soll, die bei harmlosen Refactorings brechen

Wer vom tdd skill am meisten profitiert

Der tdd skill passt am besten, wenn du bereits Folgendes hast:

• eine Codebasis mit ausführbaren Tests
• eine klar definierte öffentliche API, Route, CLI-Command oder einen User-Workflow als Ziel
• die Möglichkeit, sowohl Tests als auch Produktivcode zu ändern
• eine Präferenz für integration-nahe Tests statt starkem Mocking

Besonders nützlich ist er für Backend-Services, Libraries, Domänenlogik und Anwendungsabläufe, bei denen sich Verhalten über eine reale Schnittstelle ausüben lässt.

Was diesen tdd skill von anderen unterscheidet

Der entscheidende Unterschied ist seine klare Haltung zur Testqualität:

• Verhalten testen, nicht Interna
• integration-nahe Tests bevorzugen
• nur an Systemgrenzen mocken
• kein „horizontal slicing“, bei dem erst alle Tests und danach der gesamte Code geschrieben wird
• TDD nutzen, um bessere Interfaces zu formen, nicht nur um Testabdeckung zu erhöhen

Dadurch ist die tdd usage deutlich disziplinierter als bei einem normalen Prompt wie „schreibe Tests und Implementierung“.

Was die Einführung erschweren kann

Dieser Skill passt weniger gut, wenn deine Umgebung keine Testausführung erlaubt, deine Codebasis keine stabilen öffentlichen Andockpunkte hat oder dein Team vor allem Snapshot-lastige bzw. Mock-lastige Unit-Tests möchte. Er setzt außerdem voraus, dass du in kleinen Schritten iterieren willst, statt ein komplettes Feature in einem Durchlauf erzeugen zu lassen.

So verwendest du den tdd skill

tdd in deiner Skills-Umgebung installieren

Wenn du das Skills-System aus dem Repository nutzt, ist ein typisches Installationsmuster:

npx skills add mattpocock/skills --skill tdd

Rufe danach tdd auf, wenn du das Modell Verhalten per Test-First-Workflow implementieren oder reparieren lassen willst.

Lies diese Dateien zuerst, bevor du den tdd skill intensiver nutzt

Der schnellste Weg, diesen Skill zu verstehen, ist:

1. SKILL.md
2. tests.md
3. mocking.md
4. interface-design.md
5. refactoring.md
6. deep-modules.md

Diese Reihenfolge ist wichtig. SKILL.md vermittelt die Arbeitsphilosophie, die ergänzenden Dateien konkretisieren, was in der Praxis unter „guten Tests“ und „gutem Design“ zu verstehen ist.

Verstehe den Kern-Workflow, den der tdd skill erwartet

Der Skill ist auf einen engen Zyklus ausgelegt:

1. ein kleines Verhalten auswählen
2. einen fehlschlagenden Test über eine öffentliche Schnittstelle schreiben
3. minimalen Code implementieren, damit der Test besteht
4. bei grünen Tests refaktorieren
5. mit der nächstkleineren Scheibe wiederholen

Wenn du gleich ein komplettes Feature auf einmal anforderst, verlierst du den größten Teil des Werts von tdd usage.

Starte mit einem Verhalten, nicht mit einer Implementierungsidee

Starker Input:

• „Add checkout support for expired cards. Public entrypoint is checkout(cart, paymentMethod). Existing test file is checkout.test.ts. Keep using integration-style tests.”

Schwacher Input:

• „Create classes for payment orchestration and add unit tests for each method.”

Der erste Prompt gibt dem Skill ein Verhaltensziel. Der zweite drängt ihn in Richtung Spekulation über internes Design und fragile Tests.

Gib dem tdd skill die öffentliche Schnittstelle und den Test-Command

Für gute Ergebnisse bei tdd install und Ausführung solltest du Folgendes mitgeben:

• die Funktion, Route, den CLI-Command oder die UI-Aktion, die getestet wird
• wo die Tests liegen
• den Test-Runner und den Command
• relevante Rahmenbedingungen wie DB, HTTP oder externe Services
• was gemockt werden darf und was nicht

Ein praxistaugliches Prompt-Template:

Use the tdd skill.

Goal: Add [behavior].
Public interface: [function/route/command].
Test location: [path].
Run tests with: [command].
Boundaries to mock: [external API, clock, filesystem].
Do not mock: [internal modules/classes].
Work in red-green-refactor steps and explain each step briefly.

Arbeite mit vertikalen Scheiben, nicht mit horizontalen

Eine der wichtigsten praktischen Erkenntnisse aus diesem Repository: Schreibe nicht alle Tests im Voraus en bloc. Gute tdd usage bedeutet hier:

• ein reales Szenario auswählen
• es zum Laufen bringen
• das Ergebnis die nächste Szenario-Auswahl beeinflussen lassen

So vermeidest du erfundene Abstraktionen und erhältst meist eine bessere API-Form.

Im tdd skill integration-nahe Tests bevorzugen

Das Repository bevorzugt deutlich Tests, die reale Codepfade über öffentliche APIs ausführen. In der Praxis heißt das:

• exportierte Funktionen statt privater Helper aufrufen
• Route-Handler über ihre unterstützte Schnittstelle ansprechen
• beobachtbare Ergebnisse prüfen, nicht die interne Aufrufreihenfolge
• Tests nach Fähigkeiten benennen, zum Beispiel „user can checkout with valid cart“

Wenn ein Refactoring nur Interna verändert, das Verhalten aber gleich bleibt, sollte ein guter Test in der Regel weiter grün bleiben.

Nur an Systemgrenzen mocken

Der tdd skill ist nicht gegen Mocks an sich, sondern dagegen, die eigene Implementierung zu mocken. Mocke:

• Payment-Gateways
• E-Mail-Provider
• Zeit/Zufall
• je nach Test-Setup manchmal Datenbanken oder das Dateisystem

Nicht mocken solltest du:

• deine eigenen Module
• interne Kollaborateure
• private Methoden
• dünne Wrapper, die du selbst kontrollierst

Allein diese Leitlinie verändert die Ausgabequalität stärker als die meisten Prompt-Anpassungen.

Forme den Code auf Testbarkeit, bevor du zu viel Code schreibst

Die Begleitdateien machen einen wichtigen Punkt klar: Bessere Interfaces machen TDD leichter. Bitte das Modell, Code zu bevorzugen, der:

• Abhängigkeiten entgegennimmt, statt sie intern zu erzeugen
• Ergebnisse zurückgibt, statt versteckten Zustand zu mutieren
• eine kleine öffentliche Oberfläche behält

Wenn dein aktuelles Design Tests unnötig schwer macht, lass das Modell zuerst eine kleinere, besser testbare öffentliche Schnittstelle vorschlagen.

Ein starkes Prompt-Beispiel für den tdd skill

Use the tdd skill to add password reset token expiry.

Context:
- Node + TypeScript
- Public API: `requestPasswordReset(email)` and `resetPassword(token, newPassword)`
- Tests: `src/auth/password-reset.test.ts`
- Run with: `pnpm test password-reset`
- Mock only email sending and time
- Do not mock repository code or internal services

Please:
1. choose the smallest failing behavior first
2. write integration-style tests through public APIs
3. implement minimum code to pass
4. refactor after green
5. avoid asserting internal call counts unless at an external boundary

Das funktioniert, weil es dem Skill ein klares Ziel, eine Boundary-Policy und einen realen Ausführungspfad gibt.

Woran du gute Ausgabequalität beim tdd skill erkennst

Ein gutes Ergebnis aus diesem tdd guide enthält in der Regel:

• Tests, deren Namen sich an sichtbarem Verhalten orientieren
• jeweils nur ein kleines Szenario
• minimale Implementierung pro Schritt
• Refactoring-Hinweise nach Grün
• wenig oder gar keine Kopplung an private Strukturen

Ein schwaches Ergebnis enthält typischerweise:

• viele Mocks für internen Code
• Assertions über Aufrufreihenfolgen
• riesige Test-Suiten schon im ersten Schritt
• spekulative Abstraktionen, bevor überhaupt Verhalten grün ist

FAQ zum tdd skill

Ist tdd nur für komplett neue Features geeignet?

Nein. Der tdd skill eignet sich auch sehr gut für Bugfixes. In vielen gewachsenen Codebasen ist der beste erste Schritt ein fehlschlagender Regressionstest, der den Bug über die öffentliche Schnittstelle reproduziert – danach folgt ein minimaler Fix und anschließend Aufräumen.

Ist dieser tdd skill anfängerfreundlich?

Ja, sofern du bereits weißt, wie du die Tests deines Projekts ausführst. Die Leitlinien sind meinungsstark, aber einfach: Verhalten testen, Scheiben klein halten und Assertions auf Implementierungsdetails vermeiden. Absolute Einsteiger brauchen trotzdem oft zusätzliche Hilfe, um Architektur und Test-Tooling des Projekts zu verstehen.

Worin unterscheidet sich tdd davon, eine KI einfach Tests schreiben zu lassen?

Normale Prompts erzeugen oft auf Coverage ausgerichtete oder stark Mock-lastige Tests. Der tdd skill lenkt das Modell stärker in Richtung:

• Verhaltensspezifikationen
• sichereres Refactoring
• sauberere Interfaces
• kleinere iterative Schritte

Das verändert sowohl die Tests als auch das Produktionsdesign.

Wann sollte ich tdd nicht verwenden?

Überspringe oder begrenze tdd for Test Driven Development, wenn:

• das Verhalten noch nicht sinnvoll ausgeübt werden kann
• die Umgebung während der Iteration zu schwer auszuführen ist
• du explorative Wegwerf-Spikes baust
• die Aufgabe überwiegend mechanisch ist, etwa Umbenennungen oder Dependency-Bumps

Du kannst später immer noch zu TDD zurückkehren, sobald die öffentliche Schnittstelle klarer ist.

Verlangt tdd ausschließlich Integrationstests?

Nicht strikt, aber die Tendenz geht klar zu integration-nahen Tests über reale Interfaces. Das Ziel ist nicht maximale Testgröße, sondern Verhalten an einer stabilen Schnittstelle zu testen. Kleine fokussierte Tests sind weiterhin völlig in Ordnung, solange sie an der öffentlichen Schnittstelle bleiben und keine interne Kopplung erzeugen.

Für welche Sprachen oder Frameworks passt dieser Skill?

Die Ideen sind weitgehend sprachunabhängig. Die Beispiele sind eher auf TypeScript und JavaScript ausgerichtet, aber die Designprinzipien gelten genauso für Python, Java, Go, Ruby und ähnliche Ökosysteme – überall dort, wo sich klare öffentliche Schnittstellen und Testgrenzen definieren lassen.

So verbesserst du den tdd skill

Gib tdd eine kleinere erste Scheibe

Der einfachste Hebel für bessere tdd-Ergebnisse ist ein kleinerer erster Schritt. Statt „build user invitations“ solltest du mit „user with valid email can request an invitation“ starten. Kleinere Scheiben reduzieren halluzinierte Architektur und führen zu saubereren Tests.

Formuliere Boundary-Regeln ausdrücklich

Viele schlechte Ausgaben entstehen durch unklare Mocking-Regeln. Sage dem Modell genau:

• welche externen Systeme gemockt werden dürfen
• welche internen Module echt bleiben müssen
• ob eine Test-DB verfügbar ist
• ob Zeit injiziert oder eingefroren werden soll

So bleibt der Skill näher an der Philosophie des Repositorys.

Bitte um Testnamen über öffentliche Schnittstellen

Wenn du bessere Tests willst, fordere Namen an, die Ergebnisse beschreiben:

• gut: user can checkout with valid cart
• schwächer: checkout calls payment service

Schon diese eine Anweisung verhindert oft das Abrutschen in Implementierungsdetails.

Mache Red-Green-Refactor sichtbar

Wenn die erste Antwort als kompletter Implementierungsblock zurückkommt, bitte das Modell um eine Neu-Strukturierung:

• zeige den ersten fehlschlagenden Test
• zeige den minimalen Code zum Bestehen
• erkläre das Refactoring separat
• stoppe bei Bedarf nach einer einzigen Scheibe

Der tdd skill funktioniert am besten, wenn der Zyklus sichtbar ist und nicht nur implizit mitschwingt.

Verbessere das Design, wenn sich Tests sperrig anfühlen

Wenn das Modell Schwierigkeiten hat, saubere Tests zu schreiben, liegt das Problem oft eher im Interface-Design als in der Testsyntax. Bitte es um eine Überarbeitung in Richtung:

• dependency injection
• explizite Ein- und Ausgaben
• kleinere öffentliche Oberflächen
• weniger Seiteneffekte

Hier werden interface-design.md und deep-modules.md besonders wertvoll.

Nutze Refactoring als eigenen Qualitätsdurchgang

Nach ein paar grünen Scheiben solltest du gezielt um einen Refactoring-Review anhand der Hinweise aus dem Repository bitten:

• duplication
• long methods
• shallow modules
• feature envy
• primitive obsession

So bleibt tdd usage nicht bei „Tests laufen“ stehen, sondern verbessert auch die Wartbarkeit, ohne das Verhalten zu verändern.

Korrigiere typische Fehlermuster früh

Wenn die Ausgabequalität nachlässt, sind das meist die Ursachen:

• zu viel generierter Code vor dem ersten fehlschlagenden Test
• internes Zusammenspiel wird stark gemockt
• Tests prüfen Implementierungsdetails
• die Feature-Anforderung ist für einen Zyklus zu groß
• die öffentliche Schnittstelle ist unklar oder ändert sich in jedem Schritt

Dann hilft ein Reset auf genau ein Verhalten, eine Schnittstelle und einen fehlschlagenden Test.

Nutze Repository-Dateien als Entscheidungshilfe

Für bessere Ergebnisse solltest du dein Problem gezielt den Begleitdokumenten zuordnen:

• tests.md, wenn der Teststil schwach ist
• mocking.md, wenn Boundary-Entscheidungen unklar sind
• interface-design.md, wenn die Schnittstellen sperrig wirken
• refactoring.md nach Grün
• deep-modules.md, wenn die API-Form zu breit wird

Dieser Leseweg bringt mehr als ein bloßes Überfliegen von SKILL.md.

Iteriere, indem du Constraints verschärfst, nicht indem du denselben Prompt wiederholst

Wenn die erste Ausgabe nur mittelmäßig ist, sage nicht einfach „try again“. Verbessere die nächste Runde mit konkreten Constraints:

• genau ein Verhalten als Ziel
• bestehende öffentliche API beibehalten
• keine internen Module mocken
• eine Test-DB Repository-Mocks vorziehen
• nach dem ersten Red-Green-Refactor-Zyklus stoppen

Diese Art der Iteration verbessert die Qualität eines tdd guide deutlich zuverlässiger, als nur nach mehr Details zu fragen.