Hauptgedanke

Wer seinen Code selbst geschrieben hat, beherrscht ihn aus dem Gedächtnis: Er weiß, was er entschieden hat, wo er eine Abkürzung genommen hat, welche Teile sich berühren. Wenn ein Assistent den Code mit Dutzenden Commits am Tag produziert, gibt es dieses Gedächtnis nicht. Übrig bleiben Oberflächen, die funktionieren, ein Repository, das man nicht vollständig gelesen hat, und Teile, die man nicht laut erklären könnte.

Was in dieser Lage bleibt, sind die Tests. Ein in wenigen Tagen aufgebautes Projekt kann mehrere Hundert davon haben; der Assistent lässt sie sehr oft laufen, und meistens geht nichts kaputt. Wenn doch etwas bricht, sagt der Test nicht nur, dass es ein Problem gibt: Er sagt, welches erwartete Verhalten nicht mehr eingehalten wird. Er zeigt also die Stelle an, während die kaputte Oberfläche nur meldet, dass etwas nicht stimmt.

Der Test ist hier also kein Qualitätsnachweis im üblichen Sinn. Er ist das einzige Instrument, mit dem man den Zugriff auf ein System behält, an dessen Bau man sich nicht erinnert.

Warum das wichtig ist

Das ändert das Argument, mit dem man Tests gegenüber jemandem verteidigt, der nicht codet. „Tests sind gute Praxis“ wiegt nichts gegen das Tempo; „Ohne sie hast du keine Möglichkeit zu erfahren, was die letzte Änderung in einem Code kaputt gemacht hat, den du nicht gelesen hast“ versteht man sofort.

Es zeigt auch, was man von einem Assistenten, dem man die Produktion überlässt, vorrangig verlangen sollte: nicht Abdeckung um ihrer selbst willen, sondern ein Netz, das das System im Nachhinein befragbar macht.

Nuancen und Grenzen

Halt ist keine Kontrolle. Tests finden nur, was sie beschreiben: Sie sehen weder den Zusammenbruch bei realen Datenmengen noch Sicherheitsmängel noch eine Architektur, die sich nicht mehr weiterentwickeln lässt.

Und die Anforderung lässt sich dosieren. Ein sehr einfaches internes Werkzeug mit geringem Risiko und kurzer Lebensdauer braucht keine vollständige Teststrategie – es ist wieder eine Frage der Tragweite.

Offene Fragen

• Wie erfährt man bei Code, den man nicht geschrieben hat, ob die Tests die Verhaltensweisen abdecken, auf die es ankommt, und nicht die, die leicht zu schreiben waren?