Was mir Tests beigebracht haben. Lehren aus zwei Projekten.
Tests zu schreiben fand ich zuerst nebensächlich. Dann haben Tests bei mir echten Schaden angerichtet, und ich habe verstanden, warum sie selbst Regeln brauchen.
- Datenschutz: Tests dürfen nie an echte Daten. Ein Schutz im Code und ein Prüfschritt nach jedem Lauf sichern das ab.
- Wackler: Ein Test, der mal rot und mal grün ist, zeigt oft ein echtes Problem.
- Regel: Rote Tests pushe ich nicht, und ich schaue mir den Exit-Code an, nicht nur die Ausgabe.
Ein Testlauf hat echte Daten verändert
Bei Jarvis haben Tests mehrmals Dateien im echten Datenordner geschrieben. Einmal wurde sogar eine Datei überschrieben, die der Assistent im Alltag braucht. Beim zweiten Mal hatte ein Agent die Tests über ein eigenes Skript gestartet. Vermutlich gingen dabei auch echte Testbenachrichtigungen an mein Handy.
Die Ursache war einfach: Mein Schutz erkennt einen Testlauf an den Startargumenten. Ein eigenes Skript hat ihn umgangen. Das war meine Lücke, nicht nur die des Agents.
Was ich seitdem mache
- Ein Schutzmodul erkennt Testläufe, leitet die Datenpfade um und sperrt den Datenordner für andere Nutzer.
- Tests laufen nur noch über den normalen Aufruf. Eigene Runner-Skripte sind tabu und stehen als Regel in der Projektanleitung.
- Vor jedem Lauf lege ich eine Marker-Datei an. Danach darf es im Datenordner keine neueren Dateien geben. Wenn doch, ist ein Test undicht.
- Das Benachrichtigungswerkzeug verweigert unter Tests echte Push-Nachrichten.
- Neue Datenquellen müssen in Tests ersetzt werden.
Wackelnde Tests sind Hinweise
Einige Tests bei Jarvis schlagen unter Last oder wegen der Uhrzeit fehl. Früher habe ich sie neu gestartet und weitergemacht. Ein Fall hat sich als zeitabhängig herausgestellt. Ich habe dafür ein Issue geschrieben, die Korrektur kam als PR. Ein anderer Fund der nächtlichen Testläufe war ein Schreibvorgang, der bei zwei gleichzeitigen Prozessen kollidieren konnte. Ich habe ihn auf atomares Speichern umgestellt.
Nicht jeder Wackler hat eine Ursache. Einige bleiben bei mir ungeklärt, und ich schreibe sie dann als „bekannt wacklig“ auf, statt so zu tun, als wüsste ich es. Live-Tests mit Netz und Tests mit echter Hardware sind von Natur aus unzuverlässig.
Rote Tests pushe ich nicht
Bei Agent-Board habe ich einmal gepusht, obwohl zwei Tests rot waren. Ich hatte nur die Ausgabe nach einem Stichwort durchsucht und nicht den Exit-Code geprüft. Seitdem schaue ich auf den Exit-Code. Bei Jarvis fragt mein Wächter vor einem Push außerdem nach, wenn der aktuelle Stand keinen grünen Testlauf hat. Auch ein grüner Lauf auf dem Mac reicht nicht immer: Windows testet die CI, und manche Mac-Tests sieht die Nacht-Cloud nicht.
Ein Test, der nicht echte Daten braucht, ist besser
Wo es geht, ersetze ich echte Dinge durch Attrappen. Das macht Tests schneller und sicherer. Es hat Grenzen: Eine Attrappe kann von der Wirklichkeit abweichen, und dann bleibt der Test grün, obwohl die Funktion kaputt ist.
Was ich mitnehme
Mehr Tests heißen nicht automatisch mehr Sicherheit. Wichtiger ist, dass ich ihnen vertrauen kann. Dazu gehören ein Schutz vor Nebenwirkungen, ein Blick auf Wackler und eine klare Regel, wann gepusht wird.
Gebaut und getestet mit Claude Code. Zu Jarvis nenne ich bewusst keine Details zu den persönlichen Daten.