Worum es geht: Tests galten lange als Kür, die bei Zeitdruck entfällt. Mit Agenten kehrt sich das um: Sie sind die einzige Möglichkeit, maschinell erzeugten Code in der Menge zu prüfen, in der er entsteht. Ein Test ist zugleich eine Spezifikation, die sich selbst durchsetzt.
1. Fünf Leitplanken
Läuft in Sekunden, findet Widersprüche im ganzen Projekt: falsche Datenformate, fehlende Felder, vertauschte Parameter. Die günstigste Leitplanke überhaupt – sie prüft auch Code, für den niemand einen Test geschrieben hat.
2. Was ein guter Test prüft
Ein Test beschreibt eine Erwartung an das Verhalten, nicht an die Umsetzung. „Bei einer Fläche von 500 ergibt die Preisberechnung 90.000“ bleibt richtig, egal wie die Funktion innen aussieht. „Die Funktion ruft intern berechneHilfswert auf“ bricht bei jeder Umstrukturierung – und ist deshalb ein schlechter Test.
Diese Unterscheidung ist bei Agentenarbeit entscheidend: Ein Agent strukturiert gern um. Tests, die am Verhalten hängen, überleben das und schützen; Tests, die an der inneren Struktur hängen, erzeugen nur Lärm.
3. Welche Tests zuerst
| Bereich | Priorität | Warum |
|---|---|---|
| Geld und Preise | sehr hoch | Fehler sind teuer und fallen spät auf |
| Rechte und Zugriff | sehr hoch | Fehler sind Sicherheitslücken |
| Prüfregeln für Eingaben | hoch | Viele Randfälle, leicht zu testen |
| Datenumwandlungen | hoch | Genau hier arbeitet ein Agent gern ungenau |
| Darstellung und Gestaltung | gering | Ändert sich oft, Tests veralten schnell |
4. Der Ablauf mit einem Agenten
Bewährt hat sich eine feste Reihenfolge. Zuerst beschreiben Sie das gewünschte Verhalten und lassen den Test schreiben – oder schreiben ihn selbst. Dann lassen Sie den Agenten die Umsetzung bauen, bis der Test grün ist. Anschließend prüfen Sie beides: Ist der Test sinnvoll, und macht die Umsetzung, was sie soll?
Der letzte Schritt ist nicht verzichtbar. Ein Agent, der Test und Umsetzung schreibt, kann beide aneinander anpassen, statt das Problem zu lösen – im Extremfall entsteht ein Test, der nichts prüft. Wer den Test zuerst festlegt und danach nicht mehr ändern lässt, schließt diese Lücke.
5. Ein Prüfbefehl für alles
Legen Sie einen einzigen Befehl an, der Typprüfung, Linter und Tests nacheinander ausführt – üblicherweise npm run pruefen oder ähnlich. Dieser Befehl gehört in die Projektbeschreibung, damit der Agent ihn selbst ausführen kann. Ein Agent, der seine Fehler sieht, korrigiert sie; einer, der blind schreibt, wiederholt sie.
Derselbe Befehl läuft automatisch bei jedem Commit oder jedem Pull Request. Damit kann kein Code mehr ins Projekt gelangen, der die Prüfung nicht besteht – unabhängig davon, wer oder was ihn geschrieben hat.
6. Häufige Fragen
Wie viel Testabdeckung? Die Prozentzahl ist die falsche Frage. Besser: Sind die Bereiche aus Tabelle 3.1 abgedeckt? Achtzig Prozent Abdeckung ohne Test für die Rechteprüfung sind wertlos.
Lohnen sich Tests für ein kleines Projekt? Für Preise, Rechte und Prüfregeln immer. Für den Rest nach Bedarf.
Darf der Agent Tests schreiben? Ja, und er ist gut darin. Lesen Sie sie trotzdem – die Frage ist nicht, ob der Test läuft, sondern ob er das Richtige prüft.
Stand: September 2026. Die Übungen laufen vollständig in Ihrem Browser – es wird nichts gespeichert oder übertragen.