Tests zuerst – der beste Prompt ist ein roter Test

„Bau mir eine Funktion, die Rabatte berechnet.“ Claude liefert. Der Code sieht gut aus, kompiliert und ist trotzdem falsch, weil ich vergessen habe zu sagen, dass Rabatte nicht kombinierbar sind.

Das Problem ist nicht Claude. Das Problem ist meine Beschreibung. Und die präziseste Beschreibung, die ich kenne, ist ein Test.

🔴 Der Ablauf, der bei uns funktioniert

1. Claude schreibt zuerst nur die Tests. Ausdrücklich: „Noch keine Implementierung.“
2. Ich lese die Tests. Hier entdecke ich die Lücken in meiner eigenen Anforderung.
3. Claude führt die Tests aus und bestätigt: Sie schlagen fehl.
4. Ich committe die Tests.
5. Erst jetzt: „Implementiere, bis alle Tests grün sind. Ändere die Tests nicht.“

🔁 Warum das so gut funktioniert

Claude bekommt ein klares, prüfbares Ziel. Statt einmal zu raten, läuft eine Schleife: Code schreiben, Tests starten, Fehler lesen, nachbessern. Das kann Claude ohne mich, und zwar ziemlich hartnäckig.

Und ich muss am Ende nicht jede Zeile Implementierung verstehen, um zu wissen, ob sie das Richtige tut. Die Tests sagen es mir.

💡 Mein Tipp

Den Satz „Ändere die Tests nicht“ gibt es bei uns nicht nur im Prompt. Ein PreToolUse-Hook (Teil 11) blockiert in dieser Phase Schreibzugriffe auf *.spec.ts. Wer Tests anpassen will, muss es begründen, auch die KI.

Ein Hinweis:

Claude ist erfinderisch, wenn es darum geht, Tests grün zu bekommen. Ein hart codierter Rückgabewert, ein skip, ein zu weich formuliertes expect. Schauen Sie sich den Diff deshalb genau an. Und: Tests, die Claude schreibt, testen manchmal die Implementierung statt der Anforderung. Gute Testfälle bleiben Ihre Aufgabe.

Meine Faustregel:

• Anforderung klar und prüfbar? Erst Tests, dann Code.
• Anforderung noch unklar? Erst Plan Mode (Teil 10), dann Tests.
• UI, Prototyp, Wegwerfcode? Ausprobieren und anschauen genügt.