Learning Log 1: How to TDD in the age of AI

Nach einem Jahr des Reisens ist es wieder Zeit in die Tasten zu hauen. Aber was ist jetzt der beste Weg? Das heißt es nun vor den nächsten Job-Interviews herauszufinden. Den Anfang mache ich mit einem Vortrag von Matteo Vaccari über TDD im Zeitalter von AI. Ich frage mich: Kann ich Tests trauen, die ein Agent selbst schreibt? Was bringt es, Testfälle als Spezifikationen festzulegen und wann sollte ich im Entwicklungsprozess mit dem Agenten interagieren? Ich habe mir ein kleines Beispiel bauen lassen, Fehler eingebaut und aufgeschrieben, was ich gelernt habe. Viel Spaß!

Nach zweijährigem Hiatus von Deutschland bin ich nun heimgekehrt. Wer meine sporadischen Updates verfolgt hat, weiß, dass wir erst in Kanada gelebt und dann eine einjährige Reise um die Welt angetreten haben. Es fühlt sich verrückt an, nach der ganzen Zeit wieder in Deutschland zu sein. Die Temperaturen sind noch gar nicht so niedrig, und dennoch friere ich schon als ob es tiefer Winter wäre. Nach dem ewigen Sommer, den wir auf der Reise erlebt haben, sind nun die Bäume endlich in gelb-orange Farbe getaucht. Unsere Reise führte uns durch Zentral- und Südamerika nach Südost- und Ostasien. Wir haben so viel erlebt, das müsste ich erst einmal verarbeiten, doch eine Verschnaufpause ist uns nach dieser Reise noch nicht vergönnt.

Meine Ersparnisse sind nach diesem Jahr deutlich geschrumpft, sodass nun eine neue Einnahmequelle vonnöten ist. Da kam es mir ganz recht, dass mich am Anfang der Woche gleich zwei Recruiter:innen angeschrieben haben. Das freut mich natürlich aber nun muss ich erstmal so viel nachholen um mich im Interviews nicht zu blamieren. Ich kann an einer Hand abzählen, wie oft ich im letzten Jahr Zeit hatte, etwas zu programmieren. Meine Ex-Arbeitskollege Chris von meiner Zeit bei DNAstack, erzählte mir das er nur noch Agenten für sich programmieren lässt. Wie funktioniert sowas und bekommt man damit sauberen Code zustande? Das gilt es nun herauszufinden!

Der Vortrag: Green or to Green, ist das Feature fertig oder flunkert der Agent?

Den Anfang mache ich mit einem Vortrag von Matteo Vaccari: A Harness for Behaviour: Ensuring Ai-generated Code Does What We Want - TDD in the Age of AI. Darin berichtet Matteo über seine Herangehensweise mit Agenten zu entwickeln. Kurz gesagt: Beim Programmieren mit Agentic AI können wir den Agenten nicht vertrauen. Wir können auch Tests, die ein Agent schreibt, nicht vertrauen, Stichwort Reward Hacking. Aber auch am Anfang der Entwicklungsphase, bei der ersten iteration eines Tests, gibt es eine Schwäche. Birgitta Böckeler hat TDD im Agent-Loop untersucht (Artikel). Sie weist darauf hin: Schreibt der Agent Test und Code selbst, zeigt ein roter Test nur, dass der Agent ihn ausgeführt und ein Scheitern gesehen hat. Ob der Grund der richtige war, sagt das nicht. Was ist also die Lösung?

Die Lösung, die Matteo Vaccari vorschlägt: Die Akzeptanzkriterien werden als Customer Tests formuliert. Die Fälle stehen als Spezifikationen in Dateien, in seinem Beispiel als YAML-Tabellen, und ein kleiner TestRunner führt sie aus. Das System bleibt dabei eine Black Box. Der Agent darf diese Dateien nicht umschreiben, um die Tests grün zu bekommen. Er muss zwingend den Code ändern. Das ist dem Ansatz "Approved Scenarios" von Ivett Ördög nah, den Böckeler als guten Baustein für Vertrauen in Tests nennt. Sie beschreibt ihn als halbmanuelles Testen mit einem eigenen Runner pro Anwendung: Man bestätigt Szenarien gründlich und friert sie ein, und jede spätere Verletzung muss man neu freigeben.

Mein Aha-Moment: Ich hatte Matteo so verstanden das ein Agent mittels der Spezifikationen die Tests und den Code erstellt. Stattdessen enthalten die YAML Dateien nun die Testcases welche in den Test klassen wie bei einem Parametrisierten Test aufgerufen werden. Smart, denn dadurch fällt sofort auf wenn ein Agent versucht zu schummeln, indem es die YAML Datei ändert.

Ausprobieren geht über Studieren

Ok genug der Theorie, wie könnte dieser Ansatz in einem Projekt aussehen? Um das zu verstehen, habe ich mit Claude (Opus) zuerst das Gelernte aus dem Video diskutiert. Aus diesem Gespräch ist ein Prompt entstanden, mit dem mir ein Agent lokal ein Beispiel erstellte. Das sollte mir zeigen, wie YAML-Fälle, Reader und Runner konkret aussehen.

Das Ergebnis des Prompts war bei mir ein solides Java Repository. Die geforderten Fälle hat der Agent als YAML-Dateien im Projekt abgelegt, und eine Hilfsklasse liest sie in den Tests ein. Das erinnert mich schon sehr an Behaviour Driven Development mit Cucumber.

# Normalfälle: Preis aus dem Katalog (EUR) in der gewünschten Währung.
cases:
 - name: Birne in USD
   given:
     rates: { USD: "1.10" }
   when:
     price: { item: birne, currency: USD }
   then:
     price: "2.75"

 - name: Euro braucht keinen Kurs, auch wenn der Kursdienst ausfällt
   given:
     rate_service: unavailable
   when:
     price: { item: apfel, currency: EUR }
   then:
     price: "1.00"

class ServiceCasesTest {

   @TestFactory
   Stream<DynamicTest> serviceCases() {
       return YamlCaseLoader.tests("service", c -> {
           PriceService service = new PriceService(givenRates(c), new PriceConverter(), message -> { });

           PriceService.Result result = service.price(c.text("/when/price/item"), c.text("/when/price/currency"));

           if (c.has("/then/price")) {
               assertNull(result.error(), "unerwarteter Fehler");
               assertEquals(c.text("/then/price"), result.price().toPlainString());
           } else {
               assertEquals(c.text("/then/error"), String.valueOf(result.error()));
           }
       });
   }
   private static FakeExchangeRateClient givenRates(Case c) {
       FakeExchangeRateClient rates = new FakeExchangeRateClient();
       if (c.has("/given/rate_service") && c.text("/given/rate_service").equals("unavailable")) {
           rates.makeUnavailable();
       }
       c.data().at("/given/rates").properties()
               .forEach(e -> rates.setRate(e.getKey(), new BigDecimal(e.getValue().asText())));
       return rates;
   }
}

Dann habe ich es ausprobiert und selbst zwei Fehler in den Code eingebaut, einen anderen Rundungsmodus und einen falschen Rückgabewert im PriceService. Beide Male schlug ein Test fehl. Auch das Refactoring gelang ohne Probleme, die Entkopplung funktioniert also. Die Komplexität des Codes ist natürlich sehr gering. Ob das dann im Alltag funktioniert wird sich zeigen. Was sind deine Erfahrungen dazu?

Mein aktualisierter Workflow

Ich denke so werde ich ab jetzt ein Feature in Zukunft implementieren:

1. Feature im Plan-Modus beschreiben.
2. Zusammen mit der AI die Testfälle entwerfen und als YAML-Dateien ablegen.
3. Den Agenten das Feature implementieren lassen, ohne die freigegebenen Fälle zu ändern.
4. Das Ergebnis reviewen.

Der Schutz vor Agenten-Trickserei liegt in der Trennung: Die Fälle sind Daten, der Runner ist Code. Eine geänderte erwartete Zahl fällt im Diff sofort auf, eine gelockerte Assertion im Testcode weniger. Matteo betont vor allem "Daten statt Code".

Vor einem Jahr konnte ich bereits Erfahrungen mit Agentic Developement bei DNAstack sammeln. Jeden Test den ein Agent damals schrieb, und die liebten viele Tests zu schreiben, musste ich überprüfen. Die Pull Requests der anderen Entwickler:innen wurden mit steigender Adaption von agentic supported development über die Zeit immer größer. Das führte dazu das ich mehr Zeit mit reviews der PRs verbrachte als mich um meine Tickets zu kümmern. Um die Entwickler:innen bei den Reviews zu entlasten und Cognitive Debt zu bekämpfen, also die wachsende Lücke zwischen dem vorhandenen Code und dem, was das Team davon versteht, haben wir angefangen, kleinere Pull-Requests zu schreiben. Das half uns wieder produktiver zu werden. Umso toller finde ich es, dass Javier López Fernández in seinem Artikel "How to talk with AI?" ein großes Review am Ende ebenfalls für überholt hält. Er will kleine Interaktionen mit der AI: pro Schritt eine einzelne Test-Assertion oder eine kurze Interface-Definition, die sich in Sekunden prüfen lässt, dazu Trunk-Based Development und laufendes Review. Für mich klingt das weniger danach, die Programmierung an einen Agenten abzugeben, und mehr nach gemeinsamem Arbeiten, ähnlich wie Pair Programming. Mein Ablauf lässt den Agenten dagegen ein ganzes Feature allein umsetzen. Javiers Weg gefällt mir bisher eher. Ich vertraue den Agenten aus meiner Erfahrung nicht zu qualitativen Code zu schreiben. Es wird sich zeigen ob Agentic-Loop oder Agentic Pairing besser performen wird. Ich habe da ein OpenSource Projekt mit dem ich das in naher Zukunft mal ausprobieren werde. Bleibt also gespannt!

Was haben wir nun gelernt?

Der Exkurs über den Vortrag von Matteo und die Artikel von Birgitta Böckeler und Javier López Fernández hat mir einiges klarer gemacht. Einem Agenten und den Tests, die er selbst schreibt, kann ich nicht ohne Weiteres trauen. Das kannte ich schon aus meiner Arbeit bei DNAstack. Wenn die Testfälle als Daten vorab festliegen, fällt jede Änderung daran im Review auf, sofern ich zuerst allein die Testdateien erstelle. In meinem kleinen Beispiel haben die Tests die beiden eingebauten Fehler gefangen, und das Refactoring hat auch nichts kaputt gemacht.

Eine Best Practice gibt es aus meiner Sicht noch nicht. Mein Eindruck ist, dass es zwei Lager gibt: kleine Schritte mit laufendem Review und Trunk-Based Development (López Fernández) auf der einen Seite, Spezifikation vorab und ein Agenten-Loop (Vaccari, Approved Scenarios von Ivett Ördög erweitern) auf der anderen.

Wo es bei mir hakt

Der TestRunner ist ja Java-Code und in meinem Beispiel durch nicht geschützt. Nur die YAML-Dateien sind per Regel in der CLAUDE.md gesperrt. Ein Agent könnte also am TestRunner schummeln.

Hierbei kannst du dich zwischen den Lagern entscheiden. Entweder bist du Teil des optimistischen Lagers, dann wirst du noch mehr AI einsetzten: Ein zweiter Agent prüft, ob die Fälle wirklich eingelesen und ausgeführt werden. Er hätte ein anderes Ziel, nämlich Probleme zu finden, während der erste Tests grün bekommen soll. Ob das funktioniert, weiß ich nicht. Beide Agenten laufen meist auf demselben Modell, und auch ein Prüfer könnte sich die Arbeit leicht machen.

Im anderen Lager das AIs kritischer sieht würde ich vermuten das der Mensch mehr gefragt ist. Nur ein händisches Review kann wirkliche Klarheit schaffen ob die Tests testen was sie sollen. Ich schätze da werden wir nicht herumkommen.

So geht es weiter!

Das ist erst der Anfang dieser Serie. Als Nächstes will ich verstehen, was ein überhaupt ein Harness ist und was sind eigentlich Spec-Files? Danach geht es um Token-Ökonomie: Wann nehme ich welches Modell, wie wähle ich es automatisch für jede Aufgabe, wie senke ich die Kosten, und wie verfolge ich verbrauchte Token über die Zeit? Außerdem ist da noch die Frage, ob Code überhaupt noch gelesen werden sollte. Außerdem was ist eigentlich dieses neue ATDD? Du siehst ich stehe noch vor einem guten Berg an offenen Fragen, aber jetzt muss ich erstmal Fotos der Reise sortieren und meine Shorts gegen lange Hosen tauschen.

Während ich diesen Post verfasse, erreicht mich die traurige Nachricht, dass Patrick Stewart verstorben ist. Er wird für mich immer der beste Captain der Enterprise sein. Rest in Peace und Godspeed, Captain 🖖