Skip to content
NeuralSkills
Testen

TDD-Pair-Programmer

KI als TDD-Pair-Programmer nutzen — erst fehlschlagende Tests schreiben, dann gerade genug Code fuer gruene Tests implementieren.

Experte Kostenlos Veroeffentlicht: 15. April 2026
Kompatible Tools claude-codechatgptgeminicopilotcursorwindsurfuniversal

Das Problem

Test-Driven Development ist maechtig, aber mental anspruchsvoll. Der staendige Kontextwechsel zwischen “Testautor”- und “Implementierer”-Modus ist erschoepfend. Die meisten Entwickler geben TDD nicht auf, weil sie dagegen sind, sondern weil die Disziplin, vor jeder Codeaenderung einen fehlschlagenden Test zu schreiben, ermuedend ist. Ein KI-Partner, der den Red-Green-Refactor-Zyklus durchsetzt, haelt die Disziplin aufrecht und verdoppelt die Geschwindigkeit.

Der Prompt

Du bist mein TDD-Pair-Programmer. Wir folgen strikt der Red-Green-Refactor-Disziplin.

ZU BAUENDES FEATURE:
[Feature oder Verhalten in Klartext beschreiben]

SPRACHE/FRAMEWORK: [z.B. TypeScript + Vitest, Python + pytest]

Regeln fuer unsere TDD-Session:
1. **RED** — Du schreibst EINEN fehlschlagenden Test fuer das kleinste Verhaltensstueck
2. **GREEN** — Ich implementiere den minimalen Code, damit er besteht (oder du schlaegst ihn vor)
3. **REFACTOR** — Du reviewst und schlaegst Refactoring vor, waehrend Tests gruen bleiben

Nach jedem Schritt:
- Zeige mir die aktuelle Testdatei und Implementierungsdatei
- Sage mir, bei welchem Schritt wir sind (RED / GREEN / REFACTOR)
- Schlage den naechsten Test basierend auf den Feature-Anforderungen vor

Mit dem einfachsten moeglichen Testfall beginnen. Komplexitaet schrittweise aufbauen — nie vorspringen. Jeder Test soll genau EIN neues Verhalten hinzufuegen.

Jetzt beginnen: Schreibe den ersten fehlschlagenden Test.

Beispielausgabe

SCHRITT 1: RED — Erster fehlschlagender Test

// password-validator.test.ts
describe('PasswordValidator', () => {
  it('soll leere Passwoerter ablehnen', () => {
    expect(validatePassword('')).toEqual({
      valid: false,
      errors: ['Passwort ist erforderlich']
    });
  });
});

Dieser Test wird fehlschlagen, weil validatePassword() noch nicht existiert.

IHR SCHRITT: Erstellen Sie die Funktion mit gerade genug Code, um diesen Test zu bestehen.

Wann verwenden

Fuer jedes neue Feature einsetzen, bei dem die Anforderungen klar genug sind, um sie als Tests auszudruecken. Besonders effektiv fuer Geschaeftslogik, Validierungsregeln, Zustandsmaschinen und Algorithmen. Nicht geeignet fuer UI-lastigen Code oder exploratives Prototyping mit unklaren Anforderungen.

Profi-Tipps

  • Mit dem trivialen Fall beginnen — leere Eingabe, null, Null. Das sind die einfachsten Tests und etablieren die Funktionssignatur natuerlich.
  • Eine Assertion pro Test — der Versuchung widerstehen, mehrere Verhaltensweisen in einem Schritt zu testen. Jeder RED-Schritt fuehrt genau eine neue Anforderung ein.
  • Zuerst eine Test-Roadmap anfordern — prompten: “Bevor wir mit dem Codieren beginnen, liste die 8-12 Tests auf, die wir in Reihenfolge schreiben, vom einfachsten zum komplexesten.”
  • Den Refactor-Schritt ernst nehmen — nach je 3-4 gruenen Tests prompten: “Pruefe die Implementierung auf Duplikation, Benennung und Design Patterns. Schlage Refactorings vor, waehrend alle Tests gruen bleiben.”