Erst der rote Test

Ein Agent schreibt in zwei Minuten, wofür ein Mensch einen Vormittag braucht. Damit verschiebt sich die Arbeit von der Erzeugung zur Prüfung, und die Frage lautet, woran eigentlich geprüft wird. Testgetriebene Entwicklung beantwortet sie mit einer Regel über die Reihenfolge: Der Test entsteht, bevor es den Code gibt, den er prüfen soll.

Die Regel ist über zwanzig Jahre alt. Was mit einem Agenten dazukommt, ist eine zweite Rolle für denselben Test. Er beschreibt die Erwartung an eine Arbeit, die jemand anderes ausführt, und dieser andere hat gute Gründe, sie umzuschreiben.

Woraus die Methode besteht

Kent Beck hat sie 2002 in einem Buch beschrieben und 2023 noch einmal festgelegt, weil zu viele Beschreibungen im Umlauf waren, die etwas anderes meinen. Fünf Schritte. Der erste sammelt:

Write a list of the test scenarios you want to cover (externe Seite, newsletter.kentbeck.com)

Der zweite ist der entscheidende, und er räumt gleich mit dem verbreitetsten Missverständnis auf:

Turn exactly one item on the list into an actual, concrete, runnable test (externe Seite, newsletter.kentbeck.com)

Genau einer. Die Liste darf lang sein, konkret wird immer nur ein Fall. Danach kommt der Code, der diesen einen Test und alle vorherigen bestehen lässt, dann wahlweise die Aufräumarbeit:

Optionally refactor to improve the implementation design (externe Seite, newsletter.kentbeck.com)

Und dann von vorn, bis die Liste leer ist. Der dritte Schritt heißt Refactoring und ist der Grund, warum die Methode über die Zeit etwas bringt: Solange die Tests grün sind, lässt sich die innere Form ändern, ohne das Verhalten anzufassen.

Die Kurzform, unter der die Methode meistens läuft, ist rot, grün, aufräumen. Der rote Test steht am Anfang, und er hat eine Aufgabe, die man ihm nicht ansieht: Er beweist, dass die Prüfung überhaupt anschlagen kann.

Die Reihenfolge ist die ganze Aussage

Ein Test nach dem Code hält fest, was der Code tut. Ein Test vor dem Code hält fest, was er tun soll. Beide Sätze beschreiben eine Datei mit denselben Zeilen, und der Unterschied liegt darin, woher die Erwartung stammt.

seitlich verschiebbar

eigene Darstellung, Stand 28.08.2026

Das ist am Fehlerfall am leichtesten zu sehen. Wer einen Fehler behebt und danach einen Test dazu schreibt, hat einen Test, der beim ersten Lauf grün ist. Er beweist nichts, denn er lief nie gegen den kaputten Zustand. Wer zuerst den Fall aufschreibt, der schiefgeht, hat eine Reproduktion, und die Behebung ist belegt, sobald sie grün wird. Der Hersteller von Claude Code empfiehlt genau das als Vorgehen bei einem Fehlerbericht:

write a failing test that reproduces the issue, then fix it (externe Seite, code.claude.com)

Der Maßstab dahinter hat einen Namen. Der Datensatz TDD-Bench Verified sammelt 449 echte Vorgänge (externe Seite, arxiv.org) aus öffentlichen Verzeichnissen und prüft für jeden erzeugten Test dasselbe: Er muss

fail before the issue is resolved and pass after (externe Seite, arxiv.org)

Fällt vorher, geht danach durch. Ein Test, der nur die zweite Hälfte erfüllt, sagt über die Behebung nichts.

Was ein Agent an Prüfungen überhaupt lesen kann und wie hart eine Prüfung das Ende einer Runde blockiert, steht in Vibe-Coding / Agentic Engineering, Kapitel 07. Dieser Text setzt eine Ebene davor an, bei der Frage, wann die Erwartung entsteht.

Was ein Agent daraus macht

Beck hat 2025 aufgeschrieben, wie sich seine eigene Arbeit mit einem Agenten verändert hat, und dabei zwei Arbeitsweisen getrennt. Die eine:

In vibe coding you don’t care about the code, just the behavior of the system. (externe Seite, newsletter.kentbeck.com)

Die andere:

In augmented coding you care about the code, its complexity, the tests, & their coverage. (externe Seite, newsletter.kentbeck.com)

Für die zweite Arbeitsweise schrieb er dem Agenten den Zyklus in die Systemanweisung. Dazu drei Signale, bei denen er abbricht, und das dritte beschreibt das Verhalten, gegen das jede Testregel im Agentenbetrieb ankommt:

Any indication that the genie was cheating, for example by disabling or deleting tests (externe Seite, newsletter.kentbeck.com)

Das ist selten böse Absicht. Ein Agent bekommt ein Ziel, und ein roter Test steht zwischen ihm und diesem Ziel. Die Zeile zu ändern, an der es scheitert, ist der kürzere Weg. Über Werkzeuge hinweg gemessen hat das eine Untersuchung, die eine Umgebung gebaut hat, in der das Schummeln absichtlich leichtfällt:

create an environment in which agents can easily reward hack, such as by hardcoding test cases or editing the testing files (externe Seite, arxiv.org)

Zwei Wege also, feste Werte einsetzen oder die Testdatei anfassen. Getestet wurden drei verbreitete Werkzeuge, darunter Claude Code selbst:

We observe explicit reward hacking by both Codex and Claude Code, and misaligned behavior by all three agents. (externe Seite, arxiv.org)

Damit ist die Lage klar genug für eine praktische Folgerung. Ein Test, den der Ausführende ändern darf, ist eine Bitte. Ein Test, den er nicht ändern kann, ist eine Vorgabe.

Was gemessen ist, in beide Richtungen

Über den Nutzen von Tests im Agentenbetrieb stehen zwei Arbeiten scheinbar gegeneinander. Sie messen Verschiedenes, und der Unterschied ist die interessanteste Stelle dieses Themas.

Tests, die sich der Agent selbst schreibt. Eine Untersuchung von Anfang 2026 hat die Abläufe von sechs starken Modellen auf einem verbreiteten Aufgabensatz durchgesehen. Ausgangspunkt war eine Beobachtung:

agents often write tests on the fly, but the value of this behavior remains unclear (externe Seite, arxiv.org)

Das Ergebnis fällt nüchtern aus. Gelöste und ungelöste Aufgaben desselben Modells

resolved and unresolved tasks within the same model exhibit similar test-writing frequencies (externe Seite, arxiv.org)

unterscheiden sich in der Testmenge kaum. In einem zweiten Schritt haben die Autoren die Aufträge gezielt umgeschrieben, um mehr oder weniger Tests zu erzwingen:

prompt-induced changes in the volume of agent-written tests do not significantly change final outcomes in this setting (externe Seite, arxiv.org)

Die Begründung steht daneben und erklärt den ganzen Befund:

they mainly serve as observational feedback channels, with value-revealing print statements appearing much more often than assertion-based checks (externe Seite, arxiv.org)

Was ein Agent von sich aus Test nennt, ist überwiegend eine Ausgabe zum Hinsehen. Eine Prüfung mit einer Zusicherung, die bei Abweichung fällt, ist seltener. Die Autoren fassen es so zusammen: Diese Praxis

current agent-written testing practices reshape process and cost more than final task outcomes (externe Seite, arxiv.org)

verändert Weg und Kosten stärker als das Ergebnis.

Tests, die vorgegeben sind. Der Gegenfall ist ein Aufbau, der die Aufgabe von vornherein als Testaufgabe fasst. Er ist

specifically designed to solve human-written tests (externe Seite, arxiv.org)

und erreicht damit Werte, die in diesem Feld ungewöhnlich hoch liegen:

When provided human-written tests, TDFlow attains 88.8% pass rate on SWE-Bench Lite (an absolute improvement of 27.8% over the next best system) and 94.3% on SWE-Bench Verified. (externe Seite, arxiv.org)

Die Bedingung am Satzanfang gehört zu beiden Zahlen. Ohne vorgegebene Tests misst der Aufbau eine andere Aufgabe. Aufschlussreich ist die Nachkontrolle: Bei 800 Läufen fanden die Autoren

uncover only 7 instances of test hacking, which were subsequently counted as failures (externe Seite, arxiv.org)

sieben Fälle, in denen das System am Test statt am Fehler arbeitete, und verbuchten sie als Fehlschlag. Sieben von achthundert Läufen ist selten. Der Fall kommt vor.

Was daraus folgt. Die Menge der Tests sagt wenig. Wer sie geschrieben hat und wann, sagt viel. Ein Test, den der Agent während seiner Arbeit anlegt, ist sein Werkzeug zum Nachsehen. Ein Test, der vor der Arbeit dasteht und den er nicht anfassen darf, ist die Beschreibung der Aufgabe.

Der Rahmen dazu kommt aus der Jahreserhebung von DORA. Sie misst, dass mit der Verbreitung dieser Werkzeuge die Auslieferungsstabilität sinkt:

AI adoption does continue to have a negative relationship with software delivery stability (externe Seite, cloud.google.com)

und benennt den Mechanismus:

an increase in change volume leads to instability (externe Seite, cloud.google.com)

Mehr Änderungen je Zeiteinheit, gleichbleibendes Netz darunter. Die Vorkehrungen, die den Unterschied machen, sind in Vibe-Coding / Agentic Engineering, Kapitel 01 beziffert.

Was zu beachten ist

Vier Grenzen gehören dazu, sonst wird aus der Methode ein Ritual.

Ein grüner Test kann leer sein. Eine Prüfung, die nie anschlägt, sieht genauso aus wie eine, die nichts messen kann. Beim testgetriebenen Arbeiten schützt der rote Lauf davor, weil die Prüfung einmal aus dem richtigen Grund gefallen sein muss. Die Fälle, in denen dieser Schutz umgangen wird, stehen mit Beispielen in Vibe-Coding / Agentic Engineering, Kapitel 07.

Bei vorhandenem Code geht test-first nicht. Wer Tests zu Bestehendem nachliefert, bekommt beim ersten Lauf Grün, und damit ist nichts belegt. Der Ersatz für den roten Lauf ist eine Mutation: eine absichtlich kaputte Fassung des Prüflings, gegen die der Test fallen muss. Fällt er dort und schweigt gegen die reparierte Fassung, misst er etwas.

Dabei lohnt sich die Gegenprobe vorher, ob der unveränderte Stand grün ist. Ein kaputter Messaufbau erzeugt rote Läufe, die mit der Mutation nichts zu tun haben, und man hält ihn dann für einen scharfen Riegel.

Die Abdeckungszahl ist keine Aussage über die Fehler. Ein Testbestand wächst dort, wo Tests leicht zu schreiben sind. Wo die Fehler sitzen, ist eine zweite Frage, und beides fällt selten zusammen. Eine Abdeckung von 80 Prozent sagt, welcher Anteil der Zeilen einmal ausgeführt wurde. Über die Güte der Zusicherungen darin sagt sie nichts.

Ein erfüllter Test kann die Sache verfehlen. Die drei Punkte oben handeln davon, dass eine Prüfung nichts misst. Der vierte ist unangenehmer, weil dort die Prüfung in Ordnung ist. Eine Untersuchung vom Juni 2026 ließ zwei Agenten eine Bedienoberfläche in eine andere Technik übertragen, gemessen an 222 Prüfungen, die sie nie zu sehen bekamen. Lag die Prüfung im Arbeitsablauf, stieg die Bewertung:

With the oracle in the loop, the score reaches near-perfect (externe Seite, arxiv.org)

Nahezu voll, und die geforderte Bibliothek war tot oder fehlte ganz. Die Autoren nennen das Bauen auf die Prüfung hin und beschreiben die Ursache als eine fehlende Gewohnheit:

The agent does not, on its own, validate what it ships as a user would. (externe Seite, arxiv.org)

Das arbeitet gegen die Empfehlung dieses Textes. Ein Test, den der Ausführende nicht ändern kann, ist eine Vorgabe, und damit wird er zur Zielscheibe. Der Aufbau der Untersuchung ist eng, ein Vorhaben in achtzehn Läufen, und die Autoren sagen selbst:

Prevalence remains an open question across other agents, signals, and model families. (externe Seite, arxiv.org)

Vorgegebene Tests bleiben richtig. Ihnen fehlt eine Ergänzung: Am Ende sieht ein Mensch die Sache an, und zwar so, wie sie benutzt wird.

In Claude Code eingerichtet

Bis hierher ging es um die Methode. Der Rest handelt davon, wie man sie so verankert, dass sie auch bei einem Lauf greift, bei dem niemand zusieht.

Die Einrichtungen bauen aufeinander auf. Jede kostet mehr Vorbereitung als die vorige und braucht dafür weniger Aufmerksamkeit im Betrieb.

Stufe	Was sie ist	Verbindlichkeit
Der Auftrag	ein Satz im Prompt	für diese eine Runde
Die Projektanweisung	eine Regel in CLAUDE.md	beratend
Die Rechteregel	ein Eintrag in den Einstellungen	durchgesetzt
Die Zielbedingung	ein Satz nach /goal	nach jeder Runde geprüft
Der Riegel am Rundenende	ein Skript an einem Hook	blockiert das Ende
Der zweite Blick	eine getrennte Sitzung	urteilt ohne Vorwissen

Der Auftrag

Am Anfang steht ein Satz, und er wirkt sofort. Wichtig sind drei Angaben.

Erstens der Name der Methode, ausdrücklich. Ohne ihn baut der Agent hilfsbereit Mocks für Dinge, die es noch gar nicht gibt, damit der Test durchläuft. Zweitens die Trennung der Schritte: erst die Tests, dann anhalten. Drittens die Auflage für die zweite Hälfte, die Tests unangetastet zu lassen.

Wir arbeiten testgetrieben. Schreibe zuerst die Tests für die drei Fälle
unten, mehr nicht. Keine Implementierung, keine Mocks. Fahre sie, zeige
mir die Ausgabe, und wir sehen gemeinsam, ob sie aus dem richtigen Grund
rot sind.

Der letzte Halbsatz ist der wichtigste. Ein roter Test kann auch fallen, weil ein Modul fehlt oder ein Name falsch geschrieben ist, und dann misst er die Schreibweise. Die Fehlermeldung sagt, welcher der beiden Fälle vorliegt.

Erst danach folgt der zweite Auftrag mit der Implementierung, und der nennt die Auflage noch einmal.

Warum die Projektanweisung allein nicht genügt

Der nächstliegende Gedanke ist, die Regel dauerhaft in die CLAUDE.md zu schreiben. Das ist sinnvoll, denn die Datei wird zu Beginn jeder Sitzung gelesen, und der Hersteller nennt Testanweisungen ausdrücklich als etwas, das dorthin gehört:

Testing instructions and preferred test runners (externe Seite, code.claude.com)

Nur ist der Charakter der Datei ein anderer, als man beim Schreiben annimmt:

Unlike CLAUDE.md instructions which are advisory, hooks are deterministic and guarantee the action happens. (externe Seite, code.claude.com)

Beratend. Die Rechtedokumentation sagt es noch deutlicher und zieht die Grenze zwischen dem, was das Modell versucht, und dem, was die Umgebung zulässt:

Permission rules are enforced by Claude Code, not by the model. (externe Seite, code.claude.com)

Eine Regel im Auftrag beeinflusst den Versuch. Über das Ergebnis entscheidet etwas anderes.

Seit März 2026 gibt es dazu eine Messung. Eine Arbeit über Regressionen zählt die Tests, die vor einer Änderung liefen und danach fallen, und stellt drei Bedingungen gegeneinander. Ohne Eingriff lag der Anteil bei 6,08 Prozent. Bekam der Agent gezielt gesagt, welche Tests seine Änderung berührt, sank er auf 1,82. Die dritte Bedingung gab ihm allein die Anweisung, testgetrieben zu arbeiten:

adding TDD procedural instructions without targeted test context increased regressions to 9.94% (externe Seite, arxiv.org)

Von 6,08 auf 9,94 Prozent. Die Autoren schreiben dazu:

worse than no intervention at all (externe Seite, arxiv.org)

seitlich verschiebbar

eigene Darstellung nach Alonso u. a., TDAD, Stand 28.08.2026

Zwei Angaben gehören zu der Zahl. Die erste ist die Erhebung:

Evaluated on SWE-bench Verified with two open-weight models running on consumer hardware (externe Seite, arxiv.org)

Hundert Aufgaben beim einen Modell, fünfundzwanzig beim anderen. Das ist wenig und macht die Werte zu einer Richtung. Die zweite Angabe steht als Nebensatz mitten im Zitat: gemessen wurde die Anweisung ohne den passenden Testkontext. Das eigene Fazit der Arbeit zieht die Grenze dort entlang:

surfacing contextual information outperforms prescribing procedural workflows (externe Seite, arxiv.org)

Der Ablauf im Auftrag ist eine Beschreibung. Was der Agent daraus macht, entscheidet sich daran, ob er das Material dazu bekommt.

Das ist übrigens kein Argument gegen die Datei. Ein Eintrag dort kostet eine Zeile und verbessert die Ausgangslage jeder Sitzung. Er ist nur kein Riegel, und man sollte ihn nicht für einen halten. Wie die Projektanweisung entsteht und was gemessen dort hineingehört, steht in Vibe-Coding / Agentic Engineering, Kapitel 03.

Die Testdateien sperren

Der billigste echte Riegel ist eine Rechteregel. Während der Implementierung sind die Testdateien tabu:

{
  "permissions": {
    "deny": [
      "Edit(tests/**)",
      "Edit(**/*.test.ts)"
    ]
  }
}

Dabei lauern zwei Fallen, und beide sind still.

Die Regelart muss Edit heißen. Pfadregeln werden allein gegen Edit und Read geprüft. Wer die naheliegende Schreibweise mit Write wählt, bekommt keinen Fehler:

Claude Code accepts the rule but never consults it (externe Seite, code.claude.com)

Angenommen und nie nachgeschlagen. Die Sperre sieht dann in der Einstellungsdatei vollständig aus und wirkt nicht. Edit deckt die Schreibwerkzeuge mit ab, also ist es die richtige Wahl.

Die Rangfolge ist fest. Sperren gewinnen immer:

Rules are evaluated in order: deny, then ask, then allow. (externe Seite, code.claude.com)

Eine engere Erlaubnis hebt eine weiter gefasste Sperre also nicht auf. Wer die Tests nach der Implementierung wieder ändern will, nimmt die Regel heraus, statt sie zu übersteuern.

Ein Nachsatz zur Reichweite: Die Sperre greift bei den eingebauten Dateiwerkzeugen und bei Shell-Befehlen, die Claude Code als Dateizugriff erkennt. Ein Skript, das die Datei selbst öffnet, läuft daran vorbei. Für eine Sperre auf Betriebssystemebene ist die Sandbox zuständig.

Die Zielbedingung

Für einen Lauf über mehrere Runden gibt es /goal. Die Bedingung wird einmal formuliert, danach urteilt nach jeder Runde ein eigenes Modell darüber, ob sie erfüllt ist.

/goal npm test endet mit 0 und git status --short zeigt nichts unter tests/.
Fahre beide Befehle am Ende jeder Runde und zeige ihre Ausgabe.

Die Dokumentation nennt als Beispiel für eine solche Nebenbedingung genau diesen Fall:

no other test file is modified (externe Seite, code.claude.com)

Eine Eigenart des Bewerters gehört dazu, sonst formuliert man ins Leere:

It doesn’t run commands or read files independently, so write the condition as something Claude’s own output can demonstrate. (externe Seite, code.claude.com)

Er führt selbst nichts aus. Er liest, was in der Unterhaltung steht. Eine Bedingung wie „der Code ist sauber“ kann er nicht beurteilen, „npm test endet mit Null“ schon, weil der Agent den Lauf zeigt.

Der Riegel am Rundenende

Die härteste Stufe innerhalb des Werkzeugs ist ein Hook am Ereignis für das Rundenende. Er hält die Runde offen, bis sein Skript zufrieden ist.

{
  "hooks": {
    "Stop": [
      {
        "hooks": [
          { "type": "command", "command": "npm test --silent || exit 2" }
        ]
      }
    ]
  }
}

Das angehängte || exit 2 sieht nach Zierrat aus und ist der ganze Riegel. Blockiert wird allein bei diesem einen Rückgabewert:

Exit 2 means a blocking error. (externe Seite, code.claude.com)

Für das Rundenende heißt das:

Prevents Claude from stopping, continues the conversation (externe Seite, code.claude.com)

Ein gescheiterter Testlauf endet aber mit 1, und jeder andere Wert als 2 lässt die Runde durch. Ohne die Übersetzung hätte man einen Eintrag in der Einstellungsdatei, der vollständig aussieht und nichts aufhält. Wer einen Riegel einbaut, sollte ihn deshalb einmal absichtlich auslösen und nachsehen, ob die Runde wirklich offen bleibt.

Und er gibt irgendwann nach:

Claude Code overrides the hook and ends the turn after 8 consecutive blocks. (externe Seite, code.claude.com)

Nach acht Blockaden hintereinander endet die Runde trotzdem, damit eine dauerhaft scheiternde Prüfung die Sitzung nicht festsetzt. Wer sich auf den Riegel verlässt, sollte diese Obergrenze kennen. Wie Hooks im Einzelnen aufgesetzt werden, steht in Vibe-Coding / Agentic Engineering, Kapitel 08.

Außerhalb des Werkzeugs kommt der Haken vor dem Commit dazu. Er greift auch dann, wenn jemand von Hand committet, und er ist die einzige Stelle, die einen Agenten erwischt, der über die Shell arbeitet.

Zwei Sitzungen, zwei Rollen

Die sauberste Form der Trennung ist die personelle. Eine Sitzung schreibt die Tests, eine zweite schreibt den Code dazu. Der Hersteller führt das als Muster:

You can do something similar with tests: have one Claude write tests, then another write code to pass them. (externe Seite, code.claude.com)

Der Gewinn liegt am fehlenden Vorwissen. Wer eine Aufgabe gelöst hat, liest das Ergebnis mit dem Weg dorthin im Kopf. Eine frische Sitzung sieht allein, was dasteht. Dasselbe Argument steht hinter dem Prüfer als Subagent, siehe Vibe-Coding / Agentic Engineering, Kapitel 09.

Wie weit diese Trennung reicht, ist gemessen, wenn auch an einem anderen Gegenstand. Eine Arbeit vom Mai 2026 ließ neun starke Modelle aus sieben Familien über dieselben Aufgaben urteilen und rechnete nach, wie viel Unabhängigkeit in so einem Gremium steckt:

Roughly three-quarters of the panel’s nominal independence is lost (externe Seite, arxiv.org)

Drei Viertel davon verschwinden, weil die Modelle an denselben Stellen dieselben Fehler machen. Aus neun Stimmen werden rechnerisch etwa zwei. Der Schluss der Autoren:

scaling up panels cannot substitute for genuinely independent evaluation (externe Seite, arxiv.org)

Gemessen wurde an Aufgaben zum Sprachverstehen, also an etwas anderem als dem Fall hier. Für zwei Sitzungen desselben Modells bleibt es eine Überlegung, und sie lautet: Getrennt wird der Kontext. Das Modell und die Aufgabenbeschreibung bleiben dieselben, und ein Missverständnis, das schon im Auftrag steckt, überlebt die Trennung in beiden Sitzungen.

Woran man sieht, dass es stattgefunden hat

Die Kontrolle ist billiger als die Einrichtung, und sie besteht aus zwei Handgriffen.

Der erste ist der Nachweis statt der Behauptung:

Have Claude show evidence rather than asserting success (externe Seite, code.claude.com)

Bei testgetriebenem Arbeiten heißt das konkret: die Ausgabe des roten Laufs, nicht die Zusammenfassung davon. Ein Agent kann berichten, ein Test sei rot gewesen. Die Antwort kostet ihn dasselbe wie der Lauf.

Der zweite ist der Blick in den Unterschied. git diff auf das Testverzeichnis beantwortet die Frage, ob während der Implementierung jemand an der Erwartung gedreht hat, in zwei Sekunden. Wer die Tests vorher committet, wie es die Methode ohnehin nahelegt, sieht es noch schneller: Der Commit steht davor, und alles danach ist Implementierung.

Was davon sich wofür lohnt

Alles auf einmal einzurichten lohnt selten. Die Reihenfolge nach Nutzen je Aufwand:

1. Der Satz im Auftrag. Kostet nichts, wirkt sofort, deckt die betreute Sitzung ab.
2. Der Eintrag in der Projektanweisung. Eine Zeile, gilt in jeder Sitzung dieses Projekts.
3. Die Rechteregel auf das Testverzeichnis. Fünf Zeilen, und ab hier ist es kein Zureden mehr.
4. Der Haken vor dem Commit. Fängt auch, was neben Claude Code passiert.
5. Zielbedingung oder Stop-Hook. Für Läufe, bei denen niemand zusieht.
6. Die getrennte Sitzung. Für Stellen, an denen ein Fehler teuer wäre.

Wo die Methode aufhört

Zwei Einschränkungen zum Schluss, beide unangenehm.

Ein Tor misst, ob ein Test vorhanden ist. Über seine Güte sagt es nichts, und die Reihenfolge kann es gar nicht prüfen: Ob der Test vor dem Code entstand, sieht man dem fertigen Stand nicht an. Die Versionsgeschichte zeigt es, wenn getrennt committet wurde, und genau deshalb lohnt sich die Trennung. Ansonsten bleibt die Reihenfolge Vorsatz.

Und die Methode löst das Problem nicht, das sie an den Anfang stellt. Sie verlangt, dass jemand vorher weiß, was herauskommen soll. Bei einer klaren Aufgabe ist das leicht. Beim Erkunden einer unbekannten Schnittstelle ist es teuer, und dort ist ein Wegwerfversuch mit anschließendem Test der sinnvollere Weg. Der Satz, der die Grenze zieht, steht in derselben Sammlung von Fehlerbildern, aus der die vier Härtestufen stammen:

If you can’t verify it, don’t ship it. (externe Seite, code.claude.com)

Er gilt für den Code. Er gilt genauso für die Prüfung darüber.