Fähigkeiten test-driven-development
📦

test-driven-development

Sicher

Testgetriebene Entwicklung meistern

Auch verfügbar von: ZhanlinCui,DMJGilbert,Cycleaddict,davila7,DYAI2025,CodingCossack,Cygnusfear,obra

Tests nach dem Code zu schreiben, beweist nicht, dass sie tatsächlich etwas testen. Diese Skill erzwingt den Red-Green-Refactor-Zyklus, bei dem jeder Test vor der Implementierung fehlschlagen muss, um sicherzustellen, dass Tests reales Verhalten verifizieren.

Unterstützt: Claude Codex Code(CC)
📊 70 Angemessen
1

Die Skill-ZIP herunterladen

2

In Claude hochladen

Gehe zu Einstellungen → Fähigkeiten → Skills → Skill hochladen

3

Einschalten und loslegen

Teste es

Verwendung von "test-driven-development". Implementieren Sie eine Funktion, die fehlgeschlagene Operationen 3 Mal wiederholt

Erwartetes Ergebnis:

  • Schritt 1 (RED): Schreiben Sie den Test 'wiederholt fehlgeschlagene Operationen 3 Mal'
  • Schritt 2: Test ausführen - verifizieren, dass er fehlschlägt, weil Retry-Logik nicht existiert
  • Schritt 3 (GREEN): Minimale Retry-Schleife implementieren
  • Schritt 4: Test ausführen - verifizieren, dass er besteht
  • Schritt 5 (REFACTOR): Retry-Logik bei Bedarf extrahieren

Verwendung von "test-driven-development". Bug: Leere E-Mail wird im Formular akzeptiert

Erwartetes Ergebnis:

  • RED: test('lehnt leere E-Mail ab') - erwarte Fehler 'E-Mail erforderlich'
  • Verifizieren: Test fehlschlägt - Formular akzeptiert derzeit leere E-Mail
  • GREEN: Validierungsprüfung für leere E-Mail hinzufügen
  • Verifizieren: Test besteht, keine Regressionen
  • Ergebnis: Bug mit Test behoben, der Regression verhindert

Sicherheitsaudit

Sicher
v1 • 2/25/2026

This skill contains only markdown documentation explaining test-driven development methodology. All 57 static analyzer findings for external_commands are false positives - the detected backticks are markdown code fences (```) used for syntax highlighting, not Ruby shell execution. The 6 cryptographic algorithm findings and reconnaissance detections are also false positives from pattern matching on documentation text. No executable code, network calls, or filesystem operations exist in this skill.

2
Gescannte Dateien
674
Analysierte Zeilen
0
befunde
1
Gesamtzahl Audits
Keine Sicherheitsprobleme gefunden
Auditiert von: claude

Qualitätsbewertung

38
Architektur
100
Wartbarkeit
87
Inhalt
23
Community
100
Sicherheit
91
Spezifikationskonformität

Was du bauen kannst

Entwicklung neuer Funktionen

Verwenden Sie TDD bei der Implementierung neuer Funktionen, um sicherzustellen, dass jede Funktion über entsprechende Tests verfügt, die korrektes Verhalten vor dem Commit beweisen

Bugfix mit Regressionsschutz

Schreiben Sie zuerst einen fehlschlagenden Test, der den Bug reproduziert, implementieren Sie dann die Lösung, um sicherzustellen, dass der Bug nicht erneut auftritt

Refactoring mit Sicherheit

Verwenden Sie bestehende Testsuiten, um zu verifizieren, dass das Verhalten bei Code-Umstrukturierung oder -Optimierung unverändert bleibt

Probiere diese Prompts

Grundlegender TDD-Zyklus 
Ich muss [feature] implementieren. Helfen Sie mir, zuerst einen fehlschlagenden Test zu schreiben, der das erwartete Verhalten beschreibt, und führen Sie mich dann durch Red-Green-Refactor.
Bugfix mit TDD 
Bug: [Bug beschreiben]. Helfen Sie mir, einen Test zu schreiben, der diesen Bug reproduziert (sollte fehlschlagen), und implementieren Sie dann die minimale Lösung, um ihn zu bestehen.
Testqualitätsprüfung 
Überprüfen Sie meinen Test für [function]. Testet er reales Verhalten oder gemocktes Verhalten? Ist der Testname klar? Testet er eine einzige Sache?
TDD Anti-Pattern-Prüfung 
Ich bin dabei, [action] auszuführen. Prüfen Sie, ob dies TDD-Prinzipien verletzt. Teste ich gemocktes Verhalten? Füge ich nur für Tests verwendeten Code hinzu? Mocke ich ohne Verständnis?

Bewährte Verfahren

  • Beobachten Sie immer, wie der Test fehlschlägt, bevor Sie implementieren - dies beweist, dass der Test tatsächlich etwas testet
  • Schreiben Sie minimalen Code, um den Test zu bestehen - keine zusätzlichen Funktionen, kein Over-Engineering
  • Löschen Sie Implementierungscode, wenn Sie den TDD-Zyklus überspringen, und beginnen Sie neu mit Tests zuerst

Vermeiden

  • Implementierungscode schreiben, bevor der Test existiert
  • Gemocktes Verhalten testen statt reales Code-Verhalten
  • Nur für Tests verwendete Methoden zu Produktionsklassen hinzufügen

Häufig gestellte Fragen

Was ist, wenn ich bereits Implementierungscode geschrieben habe?
Löschen Sie ihn. Die Zeit ist bereits investiert. Schreiben Sie mit TDD neu, beginnend mit einem fehlschlagenden Test. Unverifizierter Code ist technische Schulden.
Kann ich Tests nach der Implementierung schreiben?
Nein. Tests, die nachträglich geschrieben werden und sofort bestehen, beweisen nichts. Sie testen, was Sie gebaut haben, nicht was erforderlich ist. TDD erfordert Test-zuerst.
Was ist, wenn der Code zu einfach zum Testen ist?
Einfacher Code bricht ebenfalls. Ein 30-Sekunden-Test verhindert zukünftige Bugs. Wenn es sich lohnt, es auszuliefern, lohnt es sich zu testen.
Wie gehe ich mit bestehendem Code ohne Tests um?
Fügen Sie Tests für bestehendes Verhalten vor Änderungen hinzu. Testen Sie zuerst das aktuelle Verhalten und verwenden Sie dann TDD für neue Funktionen.
Was ist, wenn mein Test-Setup zu komplex ist?
Komplexe Tests deuten auf komplexes Design hin. Vereinfachen Sie die Schnittstelle, extrahieren Sie Hilfsfunktionen oder verwenden Sie Dependency Injection.
Wann kann ich TDD überspringen?
Nur für Wegwerf-Prototypen, generierten Code oder Konfigurationsdateien. Für Produktionscode immer TDD verwenden, es sei denn, Ihr menschlicher Partner genehmigt eine Ausnahme.

Entwicklerdetails

Autor

sickn33

Lizenz

MIT

Repository

https://github.com/sickn33/antigravity-awesome-skills/tree/main/skills/test-driven-development

Ref

main

Dateistruktur

📄 SKILL.md

📄 testing-anti-patterns.md