Over 1000 Tests for a Hobby Game — a Waste?

Our project now has well over a thousand automated tests: around 990 on the server side, about 120 in the Unity client. For a family project, that sounds like overkill. It's the opposite — and here's why.

Tests are our second developer. As a solo project, there's nobody who says in code review: "Wait, that breaks the crafting." The tests are that colleague. Every game mechanic — recipes, oxygen, hunger, creature behavior, world passwords — has tests that run with every change. Refactoring without fear is the real win.

Fast enough not to annoy. Tests that take a quarter of an hour don't get run by anyone. That's why our CI gate is two-stage: the pull request check runs in a good three minutes with the fast tests; the complete, slow suite runs afterwards. That keeps the development loop snappy without losing coverage.

Testing Unity is its own topic. Client logic is hard to test inside a running engine. Our trick: the client's core logic lives in its own library that runs without Unity — we test that headless like normal code. Only what genuinely needs the engine runs as an EditMode/PlayMode test.

Warnings are errors. Our CI builds with "warnaserror": every compiler warning breaks the build. Sounds pedantic, but it prevents the warning graveyard in which the one important warning eventually drowns.

The honest bottom line: writing tests costs maybe a fifth of the development time. But every fixed feature stays fixed — and for a project that comes to life in the evenings after work, nothing is more valuable than the certainty that the weekend feature didn't wreck the Tuesday feature.