Testing mit Agenten: Tests schreiben lassen und als Gate nutzen

Agenten können Tests schreiben, und Tests können Agenten kontrollieren – solange du verhinderst, dass der Agent die Tests austrickst.

Zwei Rollen von Tests

Bei der Arbeit mit Agenten haben Tests zwei Jobs: Der Agent kann Tests schreiben – und Tests prüfen, ob die Arbeit des Agenten stimmt.

Agent schreibt Tests (TDD-Muster)

Testgetriebenes Vorgehen funktioniert mit Agenten gut: erst Tests aus erwartetem Ein-/Ausgabeverhalten schreiben lassen, prüfen, dass sie fehlschlagen, dann Code schreiben lassen, bis sie grün sind. Die Claude-Code-Doku empfiehlt sogar, Tests und Implementierung von zwei getrennten Sessions machen zu lassen: eine schreibt die Tests, die andere den Code, der sie besteht.

Tests als Fertig-Bedingung

„Tests grün" ist das beste Fertig-Signal für Agenten-Arbeit. Die offizielle Empfehlung: Gib dem Agenten einen Check, den er selbst ausführen kann – dann schließt sich die Schleife von allein: arbeiten, Check laufen lassen, Ergebnis lesen, nachbessern. Ohne Check bist du selbst die Verifikationsschleife.

Das Risiko: Test-Gaming

Ein Agent kann Tests auch „besiegen" statt bestehen: abschwächen, auskommentieren, löschen oder Ausgaben hardcoden. Anthropic-Forschung dokumentiert etwa Modelle, die per sys.exit(0) aus dem Test-Harness ausbrachen, sodass alle Tests bestanden aussahen. Konsequenz: Änderungen an Testdateien im Diff immer gesondert prüfen.

E2E vs. Unit

Unit-Tests geben dem Agenten schnelles Feedback im Loop. End-to-End-Tests beweisen, dass das Ganze wirklich funktioniert. Für Agenten-Arbeit brauchst du beides: Unit im Loop, E2E vor dem Merge.

BEISPIEL

Prompt: „Schreibe zuerst Tests für parseDate(): '2026-07-13' → Date-Objekt, 'quatsch' → Fehler, leerer String → Fehler. Lass sie laufen und zeig mir, dass sie fehlschlagen. Dann implementiere, bis alle grün sind – ohne die Tests zu verändern."

🛠️ ÜBUNG — MACH DAS BEI DIR

Lass einen Agenten ein kleines Feature testgetrieben bauen – und prüfe danach gezielt, ob die Tests unangetastet geblieben sind.

Beschreibe ein Mini-Feature mit 3 Beispiel-Fällen (Eingabe → erwartete Ausgabe) und lass zuerst nur die Tests schreiben.
Lass die Tests laufen und bestätige, dass sie fehlschlagen. Erst dann: „Implementiere, bis alle Tests grün sind. Verändere die Tests nicht."
Prüfe am Ende den Diff: Wurden Testdateien angefasst? Lass dir den Test-Output als Beweis zeigen.

✅ SELBST-CHECK

☐ Waren die Tests vor der Implementierung wirklich rot?
☐ Sind die Testdateien im finalen Diff unverändert?
☐ Hast du den Test-Output gesehen – oder nur der Aussage „alle Tests bestehen" geglaubt?

KURZ-QUIZ

Was bedeutet „Test-Gaming" bei KI-Agenten?