Über 1000 Tests für ein Hobby-Spiel — Verschwendung?

Unser Projekt hat inzwischen weit über tausend automatisierte Tests: rund 990 auf der Server-Seite, etwa 120 im Unity-Client. Für ein Familienprojekt klingt das nach Overkill. Es ist das Gegenteil — und hier ist warum.

Tests sind unser zweiter Entwickler. Als Solo-Projekt gibt es niemanden, der im Code-Review sagt: „Moment, das bricht doch das Crafting." Die Tests sind dieser Kollege. Jede Spielmechanik — Rezepte, Sauerstoff, Hunger, Kreaturenverhalten, Welt-Passwörter — hat Tests, die bei jeder Änderung mitlaufen. Refactoring ohne Angst ist der eigentliche Gewinn.

Schnell genug, um nicht zu nerven. Tests, die eine Viertelstunde laufen, führt niemand aus. Unser CI-Gate ist deshalb zweistufig: Der Pull-Request-Check läuft in gut drei Minuten mit den schnellen Tests; die vollständige, langsame Suite läuft danach. So bleibt der Entwicklungs-Loop flott, ohne dass Abdeckung verloren geht.

Unity testen ist sein eigenes Thema. Client-Logik testet man schlecht in einer laufenden Engine. Unser Trick: Die Kernlogik des Clients lebt in einer eigenen Bibliothek, die ohne Unity läuft — die testen wir headless wie normalen Code. Nur was wirklich Engine braucht, läuft als EditMode-/PlayMode-Test.

Warnungen sind Fehler. Unser CI baut mit „warnaserror": Jede Compiler-Warnung bricht den Build. Klingt pedantisch, verhindert aber den Warnungs-Friedhof, in dem irgendwann die eine wichtige Warnung untergeht.

Die ehrliche Bilanz: Tests schreiben kostet vielleicht ein Fünftel der Entwicklungszeit. Aber jedes gefixte Feature bleibt gefixt — und bei einem Projekt, das abends nach dem Job entsteht, ist nichts wertvoller als die Gewissheit, dass das Wochenend-Feature nicht das Dienstag-Feature zerlegt hat.