TDD

TDD ist der einzelne Skill tdd aus Matt Pococks öffentlicher Sammlung [mattpocock/skills](https://github.com/mattpocock/skills). Die offizielle Produktseite ist [skills.sh/mattpocock/skills/tdd](https://skills.sh/mattpocock/skills/tdd); der genaue Quelltext liegt im Repository unter skills/engineering/tdd/SKILL.md. Der Skill ist keine Testbibliothek und führt selbst keine Tests aus. Er liefert einem Coding-Agenten stattdessen Regeln und Begriffe, mit denen dieser Tests vor der Implementierung plant, schreibt und als dauerhaften Teil der Codebasis behandelt. Sein Kern ist der Red-Green-Zyklus: erst einen aussagekräftigen fehlschlagenden Test formulieren, dann nur genug Produktionscode schreiben, damit genau dieser Test grün wird, und erst danach den nächsten kleinen Schritt angehen.

Tests beschreiben beobachtbares Verhalten

Die Quelle verlangt Tests an öffentlichen Schnittstellen statt gegen private Methoden oder interne Zusammenarbeit. Ein guter Test liest sich wie eine Spezifikation einer Fähigkeit, etwa dass ein Nutzer mit einem gültigen Warenkorb bezahlen kann. Die konkrete Klassenstruktur darf sich später ändern, ohne dass der Test deshalb angepasst werden muss. Das schützt vor Tests, die lediglich die momentane Implementierung nacherzählen. Der Skill warnt besonders vor Mocks, die interne Mitarbeiter ersetzen, vor Datenbankabfragen als Umweg um die eigentliche Schnittstelle und vor Behauptungen, deren Erwartungswert mit derselben Logik wie der Produktcode erneut ausgerechnet wird. Erwartete Werte sollen aus einer unabhängigen Vorgabe, einem bekannten Beispiel oder der fachlichen Spezifikation stammen.

Schnittstellen vorab festlegen

In der Terminologie des Skills ist eine „Seam“ die öffentliche Grenze, an der Verhalten von außen sichtbar wird. Vor dem Schreiben eines Tests soll das Team festhalten, welche Seams geprüft werden und welche nicht. Das verhindert sowohl das ungezielte Testen jedes Details als auch spätere Diskussionen darüber, ob ein Test die Datenbank, einen HTTP-Endpunkt, eine Kommandozeile oder eine andere öffentliche API prüfen sollte. Existieren im Repository eine CONTEXT.md oder Architekturentscheidungen, sollen sie vor der Arbeit gelesen werden, damit Testnamen und Wortwahl zur Fachdomäne passen. Das ist hilfreich, ersetzt aber keine gemeinsame Entscheidung über die kritischen Pfade.

Vertikale statt horizontale Schritte

Der Skill lehnt horizontales Arbeiten ab: erst viele Tests zu schreiben und danach die gesamte Implementierung zu bauen, produziert leicht Tests für eine nur vorgestellte Struktur. Stattdessen empfiehlt er vertikale Tracer Bullets: ein Verhalten, ein Test, eine minimale Umsetzung, dann die nächste Erkenntnis. Dieser Ablauf begrenzt den Umfang jeder Änderung und macht sichtbar, ob der Test auf tatsächliche Verhaltensänderungen reagiert. Auch Refactoring wird klar getrennt: Es gehört nach erfolgreich geprüften Änderungen in einen Review-Schritt, nicht als zusätzlicher Ballast in den Red-Green-Teil.

Installation, Herkunft und Grenzen

Für die Einzelinstallation nennt die Produktseite den Befehl:

npx skills add https://github.com/mattpocock/skills --skill tdd

Für Claude Code nennt das Repository als offiziellen Plugin-Weg claude plugins install mattpocock-skills. Vor der Ausführung sollten Teams den aktuellen Repository-Inhalt und die eigene Agent-Konfiguration prüfen; ein Skill beeinflusst, wie ein Agent an Aufgaben herangeht, aber er ersetzt weder fachliche Abnahme noch eine vollständige Teststrategie. Das Repository steht unter MIT-Lizenz. Die 254.735 GitHub-Sterne wurden am 07.09.2026 für das gesamte Repository erfasst, nicht für diesen einzelnen TDD-Skill. Sterne sind eine momentane Popularitätskennzahl, kein Nachweis für Qualität, Sicherheit oder Eignung im konkreten Projekt.

Für wen der Skill passt

TDD passt für Teams und Einzelentwickler, die Agenten bei Features oder Fehlerbehebungen nicht sofort implementieren lassen möchten, sondern überprüfbare Änderungen an klaren öffentlichen Grenzen verlangen. Besonders sinnvoll ist er bei domänenreichem Code, Integrationspunkten und Änderungen, die nach Refactorings stabil abgesichert bleiben sollen. Weniger passend ist er als Ersatz für exploratives Prototyping, manuelle UX-Prüfungen oder Entscheidungen über die richtige Produktanforderung. Dort kann der Skill zwar Struktur geben, die fachliche Klärung und menschliche Prüfung bleiben jedoch notwendig.