Codex Test-Driven Development: KI erst Tests schreiben lassen und dann alles auf Grün bringen

Sie sehen im Terminal, dass Codex „alle Tests bestanden“ meldet. Beim genaueren Hinsehen steht dort aber nur das Ergebnis. Kein Befehl, keine Liste der ausgeführten Tests. Dann öffnen Sie den Diff und sehen, dass auch die Testdatei geändert wurde: Aus toEqual(42) wurde toBeTruthy(). Das Problem ist nicht, Codex grundsätzlich zu misstrauen. Das Problem ist ein „grünes“ Ergebnis ohne Nachweis. Dieser Leitfaden gibt Ihnen wiederverwendbare Prompt-Vorlagen, eine Nachweisliste und Guardrails gegen falsches Grün, damit aus „der KI vertrauen“ ein „reproduzierbare Belege prüfen“ wird.

Warum Test-First bei Codex wichtiger wird

Test-first bedeutet nicht nur „erst Tests, dann Code“. In der Codex-Arbeit werden Tests zu ausführbaren Abnahmekriterien. Codex kann Befehle ausführen, Ausgaben lesen und Dateien ändern. Aber der Maßstab für „fertig“ muss vorher klar sein.

Laut OpenAI-Codex-Dokumentation wird Codex besser, wenn die Arbeit verifizierbar ist. Wenn Sie also erklären, wie geprüft wird, welcher Befehl auszuführen ist und welches Ergebnis erwartet wird, steigt die Chance auf eine korrekte Änderung. Vage Aufgaben werden vage bearbeitet. Kleine Aufgaben lassen sich leichter testen und reviewen.

Die red-green-refactor-Schleife hat drei Phasen:

Diese drei Schritte sollten Sie nicht überspringen. Ohne Red wissen Sie nicht, ob der Test das neue Verhalten wirklich prüft. Ohne Refactor bleibt leicht zusammengeflickter Code zurück. Für Codex-Grundlagen lesen Sie den vollständigen Codex-Einstiegsleitfaden.

Red Phase: Codex nur fehlschlagende Tests schreiben lassen

In der Red Phase geht es vor allem um Einschränkung: nur Testdateien ändern, keinen Implementierungscode schreiben. Lassen Sie Codex zuerst eine Testliste aufstellen, dann einzelne Tests erzeugen und am Ende den Testlauf ausführen, um Rot zu bestätigen.

Prompt-Vorlage

Ändere nur Testdateien. Ändere keinen Implementierungscode.
Schreibe Tests für [Funktionsname] zu folgenden Szenarien:
1. [Minimalverhalten]
2. [Grenzfall]
3. [Fehlerpfad]
Führe danach `npm test` aus und füge den fehlgeschlagenen Testnamen sowie die Assertion ein.

Dieser Prompt muss „Ändere keinen Implementierungscode“ enthalten. Ohne diesen Satz kann Codex beim Schreiben der Tests nebenbei die Implementierung ergänzen und damit die Red-Verifikation zerstören.

Rot bestätigen

Nach Codex’ Arbeit fordern Sie die vollständige Testausgabe an. Rot muss an der erwarteten Assertion scheitern, nicht an einem Compile-Fehler oder einem Importproblem. Wenn Sie Folgendes sehen:

FAIL src/utils/calculator.test.ts > add > should handle negative numbers
AssertionError: expected -1 to be 42

dann prüft der Test das Verhalten für negative Eingaben und scheitert an der erwarteten Stelle. Wenn nur TypeError: Cannot find module 'calculator' erscheint, ist das ein Compile-Fehler und kein sinnvoller Testfehler.

Testliste sortieren

Lassen Sie Codex nicht auf einmal Dutzende Tests erzeugen. Beginnen Sie mit Minimalverhalten, Grenzfällen, Regressions-Bugs und Fehlerpfaden, und arbeiten Sie sich Schritt für Schritt vor. Die Testliste kann in AGENTS.md oder in einem separaten Dokument stehen, damit Codex sie Fall für Fall abarbeitet.

KiloClaw - Managed OpenClaw für Unternehmen: AI-Agent-Orchestrierung und smartes Modell-Routing

Jetzt starten →Anzeige

Grundlagen zu Unit-Tests finden Sie in Vitest Unit Testing und TDD sowie im Vitest-Praxisleitfaden.

Green Phase: Mit minimaler Implementierung auf Grün bringen

Die harte Guardrail in der Green Phase lautet: Testdateien sind tabu. Wenn ein Test fehlschlägt, darf Codex nur die Implementierung ändern. Tests dürfen nicht an die Implementierung angepasst werden.

Prompt-Vorlage

Ändere nur Implementierungsdateien. Ändere keine Testdateien.
Nimm die kleinste Änderung vor, damit die Tests bestehen.
Führe danach `npm test` aus und füge die Bestanden-Zusammenfassung ein.

Dieser Prompt muss „Ändere keine Testdateien“ enthalten. Ohne diesen Satz kann Codex Assertions ändern, Tests löschen oder Fälle skippen, um scheinbar Grün zu erreichen.

Bestanden-Zusammenfassung und Diff prüfen

Nach Codex’ Arbeit fordern Sie Testanzahl, Anzahl bestandener Tests und Laufzeit an:

PASS src/utils/calculator.test.ts (1.2s)
  add
    ✓ should add two numbers (5ms)
    ✓ should handle negative numbers (3ms)
  2 tests passed

Danach prüfen Sie den Diff. Wenn eine Testdatei in der Änderungsliste auftaucht, lehnen Sie diese Green Phase ab.

Guardrails gegen falsches Grün

Falsches Grün ist das größte TDD-Risiko. Achten Sie auf diese sechs Signale:

Diese Guardrails führt Codex nicht automatisch für Sie aus. Sie müssen sie im Review prüfen. Teams mit höherem Automatisierungsgrad können Teile davon in CI oder einen pre-commit hook verlagern.

Refactor Phase: Erst nach Grün aufräumen

Die Refactor Phase beginnt erst nach Grün. Solange Tests fehlschlagen, wird nicht refactort. Nach dem Refactoring müssen die Tests erneut laufen; der Diff allein reicht nicht.

Prompt-Vorlage

Alle Tests bestehen. Jetzt nur refactoren:
- Variablen umbenennen, damit die Absicht klarer wird
- Duplizierten Code entfernen
- Funktionen extrahieren
Keine Testdateien ändern. Danach `npm test` erneut ausführen.

In dieser Phase ändert Codex Struktur, nicht Verhalten. Wenn beim Refactoring neue Logik entsteht, ist es kein Refactor mehr, sondern eine neue Green Phase für neues Verhalten.

Tests erneut ausführen

Nach dem Refactoring muss Codex dieselbe Testsuite noch einmal ausführen. Bleiben die Tests grün, hat das Refactoring vorhandenes Verhalten nicht gebrochen. Schlägt ein Test fehl, hat die Strukturänderung Verhalten verändert und muss zurückgenommen oder korrigiert werden.

Prüfen Sie den Diff: Testdateien sollten nicht in der Änderungsliste erscheinen. Wenn doch, wurde die Refactor-Grenze überschritten.

Ein Refactoring-Beispiel finden Sie in KI-Refactoring mit Test-Sicherheitsnetz.

Nachweispaket: Codex prüfbare Belege liefern lassen

Vor dem Ende jeder Phase muss Codex diese Belege liefern:

Abnahme-Checkliste vor Abschluss

• Testbefehl und exit code
• Fehler- oder Bestanden-Zusammenfassung
• Liste geänderter Dateien
• Ob Testdateien geändert wurden
• CI status checks, falls vorhanden

Vorlage für die Abschlussantwort

Lassen Sie Codex in diesem Format antworten:

### Testergebnis
- Befehl: `npm test`
- Exit code: 0
- Bestanden: 42 Tests
- Fehlgeschlagen: 0
- Laufzeit: 1.2s

### Geänderte Dateien
- src/utils/calculator.ts
- (Testdateien wurden nicht geändert)

### Restrisiko
- Nicht abgedeckter Grenzfall: negative Eingabe

Dieses Format macht Nachweise lesbar, vergleichbar und archivierbar. Wenn Codex nur „Tests bestanden“ schreibt, können Sie nicht beurteilen, ob die Tests wirklich liefen, ob Testdateien geändert wurden oder ob Grenzfälle fehlen.

Alibaba Cloud - Top-Wahl für Entwickler, exklusiv 15 % Rabatt auf Lighthouse-Server

15 % Rabatt sichern →Anzeige

Testebenen und Befehlsbeispiele

Unterschiedliche Testebenen passen zu unterschiedlichen Prüfungen. Beginnen Sie nicht sofort mit vollständigen E2E-Tests, und verlassen Sie sich nicht nur auf Snapshot-Tests.

Entscheidungstabelle für Testebenen

Die Befehle sind Beispiele und müssen durch die Befehle Ihres Projekts ersetzt werden. Projekte nutzen unterschiedliche Frameworks: Jest, Vitest, Pytest, Playwright, GitHub Actions. Weitere Grundlagen finden Sie im Next.js-Jest-Testleitfaden.

Unit-Tests sind für Codex meist die erste sinnvolle Verifikationsebene. Sie laufen schnell, liefern klare Fehlermeldungen und lassen sich leicht in AGENTS.md dokumentieren. Integrations- und E2E-Tests prüfen Modulinteraktionen und Nutzerflüsse, sind aber schwieriger zu debuggen. Typprüfung und Lint ergänzen die Verifikation, indem sie Compile-Fehler und Stilprobleme finden. CI ist das letzte Team-Gate: Auch wenn lokal alles grün ist, müssen vor dem Merge die CI status checks bestehen.

AGENTS.md und Prompts festschreiben

Schreiben Sie TDD-Regeln in AGENTS.md, damit Codex sie vor jeder Arbeit liest. Dann müssen Sie dieselben Prompts nicht jedes Mal neu formulieren.

Kleines AGENTS.md-Beispiel

Legen Sie im Projekt-Root oder in einem lokalen Verzeichnis etwa Folgendes ab:

## Test commands
- Run tests: `npm test`
- Run unit tests: `npm run test:unit`
- Run typecheck: `npm run typecheck`

## TDD rules
- Red phase: only modify test files
- Green phase: only modify implementation files
- Refactor phase: must re-run tests after cleanup

## Done when
- All tests pass
- Test files are not modified in green/refactor phase
- Diff contains only expected changes

Diese Datei sagt Codex, welche Testbefehle existieren, was jede Phase ändern darf und was als fertig gilt. Weitere Hinweise zu AGENTS.md stehen im Codex-Projektregel-Artikel dieser Serie.

Lokale Verzeichnisse können konkretere Regeln enthalten. Zum Beispiel kann src/utils/AGENTS.md die Testszenarien, Grenzfälle und bekannten Bugs für src/utils/ aufführen.

Schreiben Sie keine Secrets, Token oder sensiblen Konfigurationen in AGENTS.md. Codex liest diese Datei, filtert sensible Werte aber nicht automatisch heraus.

Von lokalem Grün zu Team-CI-Gates

Lokal grüne Tests bedeuten nicht, dass gemergt werden darf. In Teams gibt es CI-Gates: required status checks müssen bestehen, und PR review muss abgeschlossen sein.

Ablauf-Checkliste

1. Lokale Tests sind grün: Codex hat die drei Phasen abgeschlossen und das Nachweispaket geliefert
2. Diff im review pane prüfen: Sehen Sie nach, ob Testdateien geändert wurden
3. PR erstellen: In einen feature branch pushen
4. Required status checks müssen bestehen: CI führt vollständige Tests, typecheck und lint aus
5. Menschliches Review: Diff, Nachweispaket und Restrisiken prüfen

Grüne Tests bedeuten keinen automatischen Merge

GitHub Docs erklären, dass required status checks bestehen müssen, bevor in einen protected branch gemergt werden kann. Es gibt aber ein Risiko: Ein skipped job meldet success und blockiert den PR-Merge nicht, selbst wenn er ein required check ist. Dadurch kann ein PR mergebar wirken, obwohl bestimmte Prüfungen nicht wirklich liefen.

Um falsches Grün durch übersprungene Workflows zu vermeiden, öffnen Sie die GitHub Checks-Seite und prüfen Sie, ob alle required checks tatsächlich ausgeführt wurden und nicht skipped sind.

Review pane nutzen

Im review pane der Codex app können Sie prüfen, ob der Diff Testdateiänderungen enthält. Sie können auf Datei- oder hunk-Ebene stage, unstage oder revert ausführen. Wenn eine Testdatei geändert wurde, revertieren Sie diese Teständerung und behalten nur die Implementierungsänderung.

Mehr CI-Hintergrund finden Sie in GitHub Actions CI und GitHub Actions Workflow Basics. Den PR-Review-Ablauf behandelt der Codex-AI-Code-Review-Artikel dieser Serie.

Railway - Moderne Deployment-Plattform, ohne DevOps-Aufwand, in Minuten live

Jetzt starten →Anzeige

Grenzen für automatische CI-Fehlerbehebung

codex exec und die Codex GitHub Action können fehlgeschlagene CI-Tests bearbeiten. Dafür brauchen sie klare Sicherheitsgrenzen.

Automatischer Ablauf zur Fehlerbehebung

Nach der Codex-Non-interactive-Dokumentation sieht ein CI-Fehlerbehebungsablauf so aus:

1. Zuerst den Test ausführen und den Fehler reproduzieren
2. Codex die kleinste Korrektur vornehmen lassen
3. Ein patch artifact erzeugen
4. Einen PR öffnen, der den Fix getrennt enthält

Mit npm test 2>&1 | codex exec "Fehlerursache zusammenfassen und kleinste Korrektur vorschlagen" können Sie Testausgabe an Codex übergeben, damit es den Fehler zusammenfasst und eine minimale Reparatur vorschlägt.

Sicherheitsprinzipien

Geben Sie Codex nicht gleichzeitig Schreibzugriff auf das Repository und Zugriff auf Secrets im selben Job. Nutzen Sie den kleinsten passenden Sandbox-Modus: standardmäßig read-only, workspace-write nur für das Arbeitsverzeichnis und danger-full-access nur in kontrollierten Umgebungen.

Trennen Sie die Erzeugung des patch artifact vom Erstellen des PR, damit API keys nicht an nicht vertrauenswürdigen Code gelangen.

Ein vollständiges GitHub-Actions-YAML gehört hier nicht hin. Die Prinzipien reichen: minimale Rechte, getrennte Patches, menschlicher Merge. Mehr Automatisierung behandelt der codex-exec-Automation-Artikel dieser Serie.

Zusammenfassung

Codex-Test-Driven-Development besteht im Kern aus drei Phasen: Red schreibt nur Tests, Green ändert nur die Implementierung, Refactor räumt nach bestandenen Tests auf und führt sie erneut aus. Jede Phase muss prüfbare Nachweise liefern: Befehl, Fehler- oder Bestanden-Zusammenfassung und geänderte Dateien.

Die Guardrails gegen falsches Grün sind der wichtigste Unterschied: Prüfen Sie, ob Testdateien geändert wurden, Assertions abgeschwächt wurden, Tests geskippt wurden, Fixtures geändert wurden, nur Unit-Tests statt relevanter Integrationstests liefen oder der CI-Workflow übersprungen wurde.

Im Team reicht lokales Grün nicht. CI status checks, PR review und protected-branch-Regeln entscheiden, ob gemergt werden darf.

Wenn Sie Codex das nächste Mal Code ändern lassen, lassen Sie es zuerst den Test schreiben, Red bestätigen und dann die Nachweise liefern. Stoppen Sie nicht bei den Worten „Tests bestanden“.