test-driven-development

Überblick über die test-driven-development-Skill

Was die test-driven-development-Skill tatsächlich leistet

Die test-driven-development-Skill gibt einem KI-Agenten einen strikten TDD-Workflow für Feature-Arbeit, Bugfixes und Verhaltensänderungen vor: zuerst einen Test schreiben, bestätigen, dass er aus dem richtigen Grund fehlschlägt, dann den minimalen Produktionscode schreiben, damit er besteht, und anschließend sicher refaktorieren. Der eigentliche Wert liegt nicht in „schreib auch noch Tests“, sondern darin, die Reihenfolge konsequent durchzusetzen, sodass die Implementierung von ausführbarem Verhalten getrieben wird.

Für wen diese Skill am besten geeignet ist

Diese test-driven-development skill passt besonders für Entwickler, die KI in echten Repositories einsetzen, bei denen Korrektheit zählt: App-Features, Service-Logik, Bugfixes, Refactorings und das Verhindern von Regressionen. Besonders nützlich ist sie, wenn du verhindern willst, dass das Modell direkt in die Implementierung springt, statt in kleinen, überprüfbaren Schritten zu arbeiten.

Der eigentliche Job-to-be-done

Die meisten installieren test-driven-development, weil generische Coding-Prompts oft zuerst Code erzeugen und Tests erst im Nachhinein daran anpassen. Diese Skill verändert genau dieses Verhalten. Sie hilft dir, eine Implementierung zu bekommen, die an fehlschlagenden Tests verankert ist, was den Agenten leichter reviewbar macht und das Risiko verringert, dass ungeprüftes Verhalten erfunden wird.

Was sie von einem generischen „write tests“-Prompt unterscheidet

Der entscheidende Unterschied ist das „eherne Gesetz“ aus der Skill: kein Produktionscode ohne zuvor fehlschlagenden Test. Das ist deutlich strenger als normales Prompting. Die Skill betont außerdem, dass der erste Fehlschlag auch der richtige Fehlschlag sein muss — nicht einfach irgendein rotes Ergebnis. Genau diese praktische Leitplanke fehlt in vielen oberflächlichen TDD-Zusammenfassungen.

Wichtige Grenzen vor der Installation

Das ist eine Prozess-Skill, kein frameworkspezifisches Testing-Toolkit. Sie entwirft nicht deine komplette Testarchitektur, und sie bringt außer SKILL.md und testing-anti-patterns.md keine Helper-Skripte oder umfangreichen Referenzen mit. Wenn du tiefgehende Anleitung für Jest, Pytest, JUnit oder Playwright brauchst, ist diese Skill besser als Workflow-Schicht geeignet als als vollständiges Testing-Handbuch.

So nutzt du die test-driven-development-Skill

Die test-driven-development-Skill installieren

Installiere sie aus dem Repository mit:

npx skills add https://github.com/obra/superpowers --skill test-driven-development

Wenn deine Umgebung lokale Skill-Erkennung unterstützt, prüfe vor Beginn der Feature-Arbeit, ob die Skill als test-driven-development erscheint und dem Agenten verfügbar ist.

Diese Dateien solltest du zuerst lesen

Für diese test-driven-development install- und Nutzungsstrecke solltest du mit folgenden Dateien starten:

• skills/test-driven-development/SKILL.md
• skills/test-driven-development/testing-anti-patterns.md

Lies zuerst SKILL.md, um Workflow und Einschränkungen zu verstehen. Lies danach testing-anti-patterns.md, wenn deine Aufgabe Mocks, Isolation, UI-Tests oder die Versuchung beinhaltet, ausschließlich für Tests gedachte Schnittstellen in Produktionscode einzubauen.

Welche Mindesteingaben die Skill braucht

Die Skill funktioniert am besten, wenn du Folgendes mitgibst:

• das Feature, den Bug oder die gewünschte Verhaltensänderung
• die relevanten Dateien oder Modulgrenzen
• das Test-Framework, das im Repository bereits verwendet wird
• das gewünschte sichtbare Verhalten für Nutzer oder das System
• etwaige Vorgaben zu API-Form, Rückwärtskompatibilität oder Performance

Ohne diesen Kontext kann der Agent TDD zwar mechanisch anwenden, wählt aber womöglich die falsche Testebene oder erzeugt unhandliche Tests, die eher zum Tool als zur Codebasis passen.

Eine grobe Anfrage in einen TDD-tauglichen Prompt verwandeln

Schwacher Prompt:

Add support for password reset.

Stärkerer Prompt:

Use the test-driven-development skill. We need password reset in the existing Node/Express app. Write the first failing integration or service-level test before any production code. Verify the failure is for missing reset behavior, not setup issues. Then implement the minimum code to pass. Keep the current route style, use Jest, and avoid changing unrelated auth flows.

Die stärkere Variante gibt dem Agenten genug Kontext, um den richtigen ersten Test zu wählen und den Red-Green-Refactor-Zyklus einzuhalten.

Die Skill als schrittweisen Workflow nutzen, nicht als große Einmal-Generierung

Ein praxistaugliches Muster für die test-driven-development-Nutzung ist:

1. Bitte zunächst nur um den ersten fehlschlagenden Test.
2. Prüfe, ob der Fehlschlag wirklich auf das beabsichtigte Verhalten zielt.
3. Bitte dann um die minimale Implementierung, damit der Test besteht.
4. Bitte erst nach Grün um Refactoring.
5. Wiederhole das für die nächste kleine Verhaltensscheibe.

So bekommst du bessere Ergebnisse, als wenn du das komplette Feature in einem Schritt anforderst, denn die Skill ist auf kleine, validierte Inkremente ausgelegt.

Die „Red“-Phase korrekt prüfen

Ein zentrales Detail in diesem test-driven-development-Leitfaden: Ein fehlschlagender Test allein reicht nicht. Der Fehlschlag muss belegen, dass der Test auf das richtige, noch fehlende Verhalten zielt. Wenn der Test wegen Importfehlern, kaputter Fixtures oder eines anderen Setup-Problems scheitert, hat der Zyklus in Wahrheit noch gar nicht begonnen.

Bitte den Agenten im Prompt ausdrücklich darum, zu erklären, warum der Test fehlschlägt und warum genau dieser Fehlschlag der richtige ist.

Den richtigen ersten Test wählen

Der beste erste Test zielt meist auf die kleinste extern sinnvolle Verhaltensänderung. Gute Kandidaten sind etwa:

• die Reproduktion eines Bugs
• genau eine Business-Regel
• genau eine Änderung an einer Endpoint-Antwort
• das Verhalten einer einzelnen Domain-Methode
• eine UI-Interaktion mit klarem Nutzer-Impact

Schlechte Einstiege sind große End-to-End-Szenarien, breit angelegte Snapshot-Abdeckung oder Tests, die interne Implementierungsdetails zu früh festschreiben.

Die Anti-Pattern-Hinweise anwenden, sobald Mocks auftauchen

Die Begleitdatei testing-anti-patterns.md wird wichtig, wenn der Agent anfängt, Mocks übermäßig zu verwenden. Die Skill warnt ausdrücklich davor, Mock-Verhalten statt echten Verhaltens zu testen. Das ist besonders relevant für test-driven-development for Test Automation, weil KI-Agenten oft Assertions gegen Mock-Platzhalter erzeugen, da diese leichter zu erfüllen sind als reale Ergebnisse.

Wenn ein Test nur behauptet, dass ein Mock gerendert wurde, ein Mock auf triviale Weise aufgerufen wurde oder eine nur für Tests gedachte Methode in den Produktionscode eingebaut werden musste, solltest du stoppen und den Test neu zuschneiden.

Den Agenten an das eherne Gesetz erinnern

Wenn das Modell bereits eine Implementierung entworfen hat, ist die Guidance der Skill eindeutig: Produktionscode löschen und mit einem fehlschlagenden Test neu starten. In der Praxis musst du daraus kein großes Theater machen, solltest dem Agenten aber klar sagen, dass er vorherigen spekulativen Implementierungscode ignorieren und die Lösung aus einer Test-first-Sequenz neu herleiten soll.

Nützliche Formulierung:

Do not continue from implementation-first code. Restart with a failing test and derive the implementation from that test.

Die Skill an den Test-Stack deines Repositories anpassen

Die Skill ist prozessorientiert, deshalb solltest du sie an deinen Stack anbinden:

• pytest für Python-Services
• Jest oder Vitest für JS/TS-Logik
• RSpec für Ruby
• JUnit für Java
• Playwright oder Ähnliches nur dann, wenn das Verhalten wirklich auf Browser-Ebene angesiedelt ist

Wenn dein Repository bereits eine saubere Testpyramide hat, sag dem Agenten, wo diese Änderung hingehört. Sonst greift das Modell unter Umständen zum sichtbarsten Teststil statt zum günstigsten sinnvollen.

Beispiel-Prompt für realistische Repository-Arbeit

Ein guter test-driven-development skill-Prompt sieht so aus:

Use the test-driven-development skill for a bug fix. In billing/invoice_service.py, invoices with zero-amount adjustments should remain payable if tax is still due. Start by writing the smallest failing pytest that reproduces the current bug. Confirm the failure is caused by the missing business rule, not fixture issues. Then implement the minimum fix, run or describe the expected green result, and suggest any safe refactor only after the test passes.

Dieser Prompt liefert Verhalten, Ort, Framework und Review-Kriterien.

FAQ zur test-driven-development-Skill

Lohnt sich test-driven-development auch, wenn ich TDD bereits kenne?

Ja — wenn dein Hauptproblem darin besteht, KI-Agenten tatsächlich TDD folgen zu lassen, statt nur darüber reden zu lassen. Die test-driven-development skill ist weniger als Lernmaterial wertvoll, sondern eher als Verhaltensrahmen für das Modell.

Ist das anfängerfreundlich?

Überwiegend ja. Der Workflow ist einfach und klar formuliert. Der schwierigere Teil für Einsteiger ist die Wahl des richtigen ersten Tests und der passenden Testebene. Wenn du noch neu im Testing bist, nutze diese Skill zunächst bei kleinen Bugfixes statt bei großen neuen Features.

Wann passt test-driven-development eher nicht?

Weniger passend ist es für Wegwerf-Prototypen, generierten Code oder reine Konfigurationsänderungen — es sei denn, das Korrektheitsrisiko ist hoch und dein menschlicher Reviewer will trotzdem Test-first-Disziplin. Die Quell-Guidance behandelt solche Fälle ausdrücklich als Ausnahmen, die mit einem menschlichen Partner besprochen werden sollten.

Wie unterscheidet sich das von normalem Prompting?

Normale Prompts sagen oft: „implementiere X und füge Tests hinzu“. Diese Skill verändert die Arbeitsreihenfolge und behandelt sie als nicht verhandelbar. Genau diese Reihenfolge ist der eigentliche Mehrwert, weil sie halluzinierte Implementierung reduziert und die Reviewbarkeit verbessert.

Deckt diese Skill auch Framework-Setup ab?

Nicht besonders tief. test-driven-development install ist unkompliziert, aber die Skill selbst liefert keine umfangreiche frameworkspezifische Setup-Dokumentation. Sie setzt voraus, dass du den Agenten auf deinen bestehenden Test-Stack oder die Repository-Konventionen verweisen kannst.

Kann ich test-driven-development auch für Refactoring verwenden?

Ja. Sie eignet sich gut für Refactoring, wenn das Verhalten stabil bleiben muss. Das praktische Muster ist: zuerst das aktuelle Verhalten mit Tests absichern, dann mit grünen Tests im Rücken refaktorieren.

Ist das gut für UI- und End-to-End-Testing geeignet?

Manchmal, aber mit Vorsicht. Gerade bei UI-Arbeit ist die Anti-Pattern-Datei besonders wichtig, weil KI leicht dazu neigt, nur die Existenz von Mocks oder Implementierungsartefakten zu prüfen. Starte mit dem kleinsten echten Nutzerverhalten, das du zuverlässig verifizieren kannst.

So verbesserst du die test-driven-development-Skill

Verhalten beschreiben, nicht Lösungsideen vorgeben

Für bessere test-driven-development-Nutzung solltest du das erwartete Verhalten und die Randbedingungen beschreiben, statt die Implementierung vorzugeben. TDD funktioniert am besten, wenn der Test die Ergebnisse definiert und der Code aus diesen Prüfungen heraus entsteht.

Bessere Eingabe:
Users should see an error when uploading files over 10MB.

Schlechtere Eingabe:
Add a fileSizeValidator class and call it from the controller.

Die erste Variante lässt Raum für eine sauberere minimale Implementierung.

Die gewünschte Testebene ausdrücklich angeben

Viele schwache Ergebnisse entstehen durch einen unpassenden Testumfang. Sag dem Agenten, ob du möchtest:

• Business-Logik auf Unit-Ebene
• Integration rund um einen Service oder eine API
• Verhalten auf Browser-Ebene

Diese eine Entscheidung hat oft mehr Einfluss als jedes andere Prompt-Detail.

Kleinere Inkremente erzwingen

Ein häufiger Fehler ist, in einem Zyklus zu viel zu verlangen. Wenn das Modell gleichzeitig eine breite Test-Suite und eine große Implementierung schreibt, grenze es ein:

Pick one failing test that captures the first slice of behavior. Do not implement the whole feature yet.

So bleibt die test-driven-development-Schleife intakt.

Eine Begründung verlangen, warum der erste Test der richtige ist

Bitte den Agenten zu begründen:

• warum genau dieser Test die kleinste sinnvolle Scheibe ist
• welcher Fehlschlag konkret zu erwarten ist
• warum genau dieser Fehlschlag beweist, dass das Verhalten fehlt

Das verbessert die Qualität, weil versteckte Annahmen sichtbar werden, bevor die Implementierung beginnt.

Früh auf Anti-Patterns achten

Die häufigsten Qualitätsverluste sind:

• Mocks statt Verhalten zu testen
• nur für Tests gedachte Methoden in Produktionscode einzubauen
• zuerst erfolgreiche Tests zu schreiben und das dann TDD zu nennen
• Assertions zu wählen, die an Implementierungsdetails hängen
• den Refactoring-Schritt nach Grün zu überspringen

Wenn du eines davon siehst, unterbrich den Zyklus und verlange einen korrigierten ersten Test, statt das Problem im Nachhinein zu flicken.

Repository-Konventionen explizit mitgeben

Die Skill wird deutlich besser, wenn du ihr sagst:

• Namenskonventionen für Tests
• wo Tests liegen
• Fixture-Muster
• Mocking-Policy
• bevorzugter Assertion-Stil

Da das Repository nur leichtgewichtiges Begleitmaterial enthält, verbessern diese lokalen Konventionen die Ausgabequalität spürbar.

Nach der ersten Ausgabe gezielt iterieren

Bitte nach dem ersten Ergebnis nicht einfach um „mehr“. Stelle gezielte Rückfragen:

• Can you make the failing test narrower?
• Is this failure due to setup or missing behavior?
• Can we remove this mock and test real behavior instead?
• What is the minimum code needed to pass?
• What refactor is now safe with tests green?

Das ist in der Praxis der wirkungsvollste Hebel, um die test-driven-development skill zu verbessern: den Agenten im Zyklus halten, statt ihn vorschnell nach vorne springen zu lassen.

Mit menschlichem Urteilsvermögen bei Ausnahmen kombinieren

Die Skill ist bewusst streng. Das ist eine Stärke, kann aber auch überzogen angewendet werden. Wenn die Aufgabe nur eine Konfigurationsänderung, ein Refresh von generiertem Code oder ein Wegwerf-Prototyp ist, solltest du hinterfragen, ob vollständiges TDD den Aufwand wert ist. Bessere Ergebnisse entstehen dort, wo die Test-first-Reihenfolge tatsächlich die Qualität von Entscheidungen verbessert — nicht nur dort, wo sie theoretisch anwendbar wäre.