Ponad 1000 testów dla hobbystycznej gry – strata czasu?

Nasz projekt ma teraz grubo ponad tysiąc automatycznych testów: około 990 po stronie serwera, około 120 w kliencie Unity. Dla projektu rodzinnego brzmi to jak przesada. Jest odwrotnie – i oto dlaczego.

Testy to nasz drugi deweloper. W projekcie jednoosobowym nikt nie powie przy code review: „Czekaj, to psuje wytwarzanie.” Testy są tym kolegą. Każda mechanika gry – przepisy, tlen, głód, zachowanie stworzeń, hasła światów – ma testy uruchamiane przy każdej zmianie. Refaktoryzacja bez strachu to prawdziwa wygrana.

Wystarczająco szybkie, żeby nie irytować. Testów, które trwają kwadrans, nikt nie uruchamia. Dlatego nasza bramka CI jest dwustopniowa: sprawdzenie pull requesta z szybkimi testami trwa dobre trzy minuty; kompletny, wolny zestaw działa potem. Dzięki temu pętla pracy pozostaje żwawa, a pokrycie nie maleje.

Testowanie Unity to osobny temat. Logikę klienta trudno testować w działającym silniku. Nasz trik: główna logika klienta mieszka we własnej bibliotece, która działa bez Unity – testujemy ją headless jak zwykły kod. Tylko to, co naprawdę wymaga silnika, działa jako test EditMode/PlayMode.

Ostrzeżenia to błędy. Nasze CI buduje z „warnaserror”: każde ostrzeżenie kompilatora psuje build. Brzmi pedantycznie, ale zapobiega cmentarzowi ostrzeżeń, w którym w końcu tonie to jedno ważne.

Uczciwy wniosek: pisanie testów kosztuje może jedną piątą czasu rozwoju. Ale każda naprawiona funkcja pozostaje naprawiona – a dla projektu, który ożywa wieczorami po pracy, nie ma nic cenniejszego niż pewność, że weekendowa funkcja nie zepsuła wtorkowej.