Meer dan 1000 tests voor een hobbyspel – overbodig?

Ons project heeft inmiddels ruim duizend geautomatiseerde tests: zo'n 990 aan de serverkant, ongeveer 120 in de Unity-client. Voor een gezinsproject klinkt dat als overkill. Het is juist het tegenovergestelde – en dit is waarom.

Tests zijn onze tweede ontwikkelaar. Bij een solo-project is er niemand die in de code review zegt: “Wacht, dit breekt het craften.” De tests zijn die collega. Elke spelmechaniek – recepten, zuurstof, honger, gedrag van wezens, wereldwachtwoorden – heeft tests die bij elke wijziging draaien. Zonder angst refactoren is de echte winst.

Snel genoeg om niet te irriteren. Tests die een kwartier duren, draait niemand. Daarom is onze CI-poort tweetraps: de pull-requestcontrole draait in ruim drie minuten met de snelle tests; de complete, trage suite draait daarna. Zo blijft de ontwikkellus vlot zonder dat we dekking verliezen.

Unity testen is een onderwerp apart. Clientlogica is moeilijk te testen in een draaiende engine. Onze truc: de kernlogica van de client zit in een eigen bibliotheek die zonder Unity draait – die testen we headless als gewone code. Alleen wat echt de engine nodig heeft, draait als EditMode/PlayMode-test.

Waarschuwingen zijn fouten. Onze CI bouwt met “warnaserror”: elke compilerwaarschuwing breekt de build. Klinkt pietluttig, maar het voorkomt het waarschuwingskerkhof waarin die ene belangrijke waarschuwing uiteindelijk verdrinkt.

De eerlijke conclusie: tests schrijven kost misschien een vijfde van de ontwikkeltijd. Maar elke gerepareerde functie blijft gerepareerd – en voor een project dat 's avonds na het werk tot leven komt, is niets waardevoller dan de zekerheid dat de weekendfunctie de dinsdagfunctie niet kapotmaakte.