test-driven-development

Überblick

Was dieser Skill macht

Der test-driven-development Skill bildet einen strikten Test-Driven Development (TDD) Workflow ab: Du schreibst immer zuerst einen fehlschlagenden Test, bevor du Produktionscode anfasst, und arbeitest danach diszipliniert im Red-Green-Refactor-Zyklus.

Anstelle von vagen „schreib irgendwann mal Tests“-Hinweisen definiert dieser Skill klare Regeln:

• Kein Produktionscode ohne vorherigen fehlschlagenden Test
• Immer sicherstellen, dass der Test aus dem richtigen Grund fehlschlägt
• Nur so viel Code schreiben, wie nötig ist, damit die Tests grün werden
• Refaktorieren, sobald alles grün ist

Außerdem verweist er auf einen eigenen testing-anti-patterns Guide, der dir hilft, fragile oder irreführende Tests zu vermeiden.

Für wen dieser Skill gedacht ist

Nutze den test-driven-development Skill, wenn du:

• Entwickler bist und einen verlässlichen Workflow für Features, Bugfixes und Refactorings suchst
• Ein Team bist, das sich auf TDD standardisieren und klare, verbindliche Regeln etablieren möchte
• Coach oder Tech Lead bist und konsequente Testautomatisierungs-Gewohnheiten durchsetzen willst

Besonders hilfreich ist er in JavaScript- und TypeScript-Codebasen, aber die Prinzipien gelten für jede Sprache und jedes Test-Framework.

Welche Probleme dieser Skill löst

Dieser Skill adressiert typische Probleme im Entwicklungsalltag:

• Zuerst Code schreiben und Tests später – oder nie – hinzufügen
• Unklarheit, ob Tests das Verhalten wirklich verlässlich prüfen
• Hemmungen beim Refactoring, weil Tests schwach oder nicht vorhanden sind
• Übermäßiger oder falscher Einsatz von Mocks, die Scheinverhalten statt echtes Verhalten testen

Wenn du dem test-driven-development Workflow folgst, erreichst du:

• Schnelles Feedback durch fehlschlagende Tests
• Eine klare Dokumentation des beabsichtigten Verhaltens
• Sichereres Refactoring, weil das Verhalten durch Tests abgesichert ist
• Weniger fragile Tests, die nicht nur Mocks oder Implementierungsdetails prüfen

Wann einsetzen (und wann nicht)

Der Upstream-Skill empfiehlt den Einsatz von TDD ausdrücklich für:

• Neue Features
• Bugfixes
• Refactoring-Arbeiten
• Jede Verhaltensänderung

Und er nennt Ausnahmen, die du mit einem menschlichen Partner abstimmen solltest, zum Beispiel:

• Wegwerf-Prototypen
• Generierten Code
• Konfigurationsdateien

Wenn du „nur mal etwas ausprobieren“ willst oder einen schnellen Spike baust, den du anschließend wegwirfst, kann dieser strikte test-driven-development Skill schwergewichtiger sein, als du brauchst. Für produktiven Code ist er jedoch als Standard-Workflow gedacht – nicht als optionales Extra.

Nutzung

Installation

Um den test-driven-development Skill aus dem obra/superpowers Repository zu installieren, führe aus:

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

Damit holst du die test-driven-development Skill-Definition und die zugehörigen Dateien in deine Agent Skills-Umgebung. Nach der Installation kannst du die Dateien des Skills öffnen, um die detaillierten Regeln und Anti-Pattern-Beispiele zu sehen.

Wichtige Dateien, auf die sich dieser Skill bezieht, sind:

• SKILL.md – die zentralen TDD-Regeln, inklusive Iron Law und Red-Green-Refactor
• testing-anti-patterns.md – ein fokussierter Guide dazu, was du in Tests nicht tun solltest

Kernprinzip: The Iron Law

Im Zentrum dieses Skills steht das, was die Quelle als Iron Law bezeichnet:

NO PRODUCTION CODE WITHOUT A FAILING TEST FIRST

Konkret bedeutet das:

• Wenn du Produktionscode vor einem Test geschrieben hast, löschst du diesen Code und beginnst noch einmal von vorn
• Du behältst ihn nicht als „Referenz“ und passt ihn nicht einfach beim Testschreiben an
• Du schaust dir den gelöschten Code beim Neu-Implementieren ausgehend von Tests nicht noch einmal an

Diese harte Regel stellt sicher, dass jede Zeile Produktionscode von einem echten Test getrieben ist.

Schritt-für-Schritt-TDD-Workflow

Sobald der test-driven-development Skill installiert ist, nutzt du ihn als deinen Standard-Workflow:

1. Failing Test schreiben (RED)

• Identifiziere genau ein Verhalten (Feature, Bugfix oder Ergebnis eines Refactorings)
• Schreibe einen neuen Test, der das erwartete Verhalten ausdrückt
• Führe die Tests aus und stelle sicher, dass dieser neue Test fehlschlägt

Der RED-Schritt ist erst erledigt, wenn du:

• Den Test fehlschlagen siehst
• Bestätigt hast, dass er aus dem richtigen Grund fehlschlägt (die richtige Assertion, der richtige Fehler)

Wenn der Fehler falsch ist (z. B. Test bricht ab oder scheitert im Setup), korrigiere den Test und führe ihn erneut aus, bis er auf sinnvolle Weise fehlschlägt.

2. Minimalen Code hinzufügen, bis der Test grün ist (GREEN)

• Implementiere nur den einfachstmöglichen Code, damit der fehlschlagende Test grün wird
• Vermeide vorgezogene Architekturentscheidungen, Abstraktionen oder zusätzliche Logik
• Führe die gesamte Test-Suite aus und stelle sicher, dass der neue Test jetzt grün ist und bestehende Tests weiterhin bestehen

Die Guidance des Skills betont, dass dieser Schritt bewusst eng gefasst ist: Dein Ziel ist nicht, „das Feature fertigzustellen“, sondern den Test zu erfüllen.

3. Sicher refaktorieren (REFACTOR)

Wenn alles grün ist:

• Säubere den Produktionscode: Duplikate entfernen, Logik vereinfachen, Namen präzisieren
• Säubere die Tests: Lesbarkeit verbessern, bei Bedarf Helfer extrahieren
• Führe die Tests häufig aus, um sicherzugehen, dass sich das Verhalten nicht geändert hat

So verbesserst du das Design, ohne das Verhalten zu verändern – abgesichert durch deine Test-Suite.

4. Zyklus wiederholen

Für jedes kleine Verhalten oder jeden Edge Case:

• Einen weiteren Test hinzufügen (RED)
• Ihn grün bekommen (GREEN)
• Nach Bedarf refaktorieren (REFACTOR)

Die Aufgabe des test-driven-development Skills ist es, dich in diesem Loop zu halten und es dir schwer zu machen, Schritte „ausnahmsweise“ zu überspringen.

Integration in deinen Tech-Stack

Die Beispiele im Repository sind auf JavaScript und TypeScript ausgerichtet, aber du kannst die TDD-Regeln unabhängig von deinem Stack anwenden:

• In JavaScript/TypeScript Projekten (z. B. mit Jest, Vitest oder Mocha):

  • Lege Tests (z. B. in *.test.ts oder *.spec.ts) immer vor Änderungen an Produktivdateien an oder passe sie zuerst an
  • Nutze den Red-Green-Refactor-Zyklus bei jeder Änderung am Anwendungscode

• In anderen Sprachen (z. B. Python, Java, Go, C#):

  • Übertrage die gleichen Schritte auf dein Test-Framework (pytest, JUnit, Go test, xUnit usw.)
  • Die strikte Regel „kein Produktionscode ohne vorherigen fehlschlagenden Test“ gilt weiterhin

Der Skill selbst bindet dich nicht an ein bestimmtes Framework; er definiert Workflow-Regeln, keine Library-Abhängigkeiten.

Den Testing-Anti-Patterns-Guide nutzen

Die Datei testing-anti-patterns.md dient als Begleiter zum test-driven-development Skill. Lade sie oder nimm sie zur Hand, wenn du:

• Tests schreibst oder änderst
• Mocks oder Stubs hinzufügst
• In Versuchung gerätst, Test-spezifische Hooks in Produktionsklassen oder -module einzubauen

Zentrale Prinzipien aus diesem Guide sind:

• Niemals Mock-Verhalten testen – Tests sollen echtes Verhalten prüfen, nicht nur das Vorhandensein eines Mocks
• Keine reinen Test-Methoden in Produktionsklassen – halte die Produktiv-APIs sauber
• Nicht mocken, ohne die Abhängigkeiten wirklich zu verstehen – zu viel Mocking erzeugt trügerische Sicherheit

Die Anti-Pattern-Beispiele nutzen TypeScript-ähnliche Tests, um schlechte und gute Tests gegenüberzustellen; du kannst sie auf dein eigenes Test-Framework übertragen.

Den Workflow an dein Team anpassen

Nach der Installation kannst du die Regeln des test-driven-development Skills an eure Realität anpassen, ohne den Kern zu verwässern:

• Einigt euch darauf, bei welchen Arten von Änderungen striktes TDD Pflicht ist (z. B. alle Produktionsmodule, Domänenlogik, kritische Flows)
• Definiert wenige, klar benannte Ausnahmefälle (z. B. schnelle Spikes oder generierter Code) – aber haltet sie explizit
• Integriert die Iron Law in eure Code-Review-Checklisten:
  • „Wo ist der fehlschlagende Test, der diese Änderung getrieben hat?“
  • „Wurde der Test zuerst geschrieben?“

So nutzt ihr den Skill als Team-Standard, nicht nur als persönliche Gewohnheit.

FAQ

Ist der test-driven-development Skill an ein bestimmtes Framework gebunden?

Nein. Der test-driven-development Skill definiert einen Workflow und Regeln, kein spezielles Test-Framework. Die Beispiele im Repository basieren auf JavaScript und TypeScript, aber du kannst denselben Red-Green-Refactor-Zyklus in jeder Sprache anwenden.

Muss ich Code, den ich ohne Tests geschrieben habe, wirklich löschen?

Gemäß der Iron Law in SKILL.md ja. Wenn du Produktionscode vor einem fehlschlagenden Test geschrieben hast, besteht die Regel darin, ihn zu löschen und anhand von Tests neu zu implementieren. Die Idee dahinter: Tests sollen niemals nachträglicher Behelf sein.

Wann ist dieser Skill nicht die beste Wahl?

Die Upstream-Guidance nennt einige mögliche Ausnahmen, etwa Wegwerf-Prototypen, generierten Code oder Konfigurationsdateien. Für kurzlebige, experimentelle Spikes kann striktes test-driven-development mehr Aufwand sein, als nötig. Für produktive Features, Bugfixes und Refactorings ist dieser Skill jedoch als Standard vorgesehen.

Wie unterstützt dieser Skill beim Debuggen und Refactoring?

Beim Beheben eines Bugs oder bei einem Refactoring:

• Schreibe zuerst einen fehlschlagenden Test, der den Bug reproduziert oder das gewünschte Verhalten beschreibt
• Ändere dann den Code, bis der Test grün ist
• Refaktorierte anschließend mit mehr Sicherheit, weil die Tests das Verhalten absichern

So wird Debugging systematischer und Refactoring deutlich sicherer.

Kann ich ihn mit bestehendem Legacy-Code ohne Tests einsetzen?

Ja, aber meist gehst du schrittweise vor:

• Wenn du einen Legacy-Bereich anfasst, schreibe zuerst einen Test, der das aktuelle oder gewünschte Verhalten abbildet
• Sieh zu, wie er fehlschlägt (falls du Verhalten änderst), und mache ihn dann grün
• Nutze den Red-Green-Refactor-Zyklus, um diesen Teil der Codebasis nach und nach unter Testabdeckung zu bringen

Mit der Zeit ist immer mehr deines Legacy-Codes durch Tests geschützt.

Wo soll ich nach der Installation anfangen?

Nachdem du den Installationsbefehl ausgeführt hast, öffne:

• SKILL.md für die zentralen test-driven-development Regeln und die Beschreibung des Red-Green-Refactor-Zyklus
• testing-anti-patterns.md für häufige Fehler, die du beim Testschreiben vermeiden solltest

Nutze diese beiden Dateien als Referenz für deinen täglichen Entwicklungs-Workflow.