does anyone actually unit test game logic or do we all just playtest and pray

Been using GUT (Godot Unit Test) for about a year. Honest answer: yes, but only for the things that actually deserve it. Damage formulas, buff stacking, inventory math, save data serialization. Pure functions with well-defined inputs and outputs. Easy to test, has caught real regressions more than once.

Where it falls apart is anything that needs a live scene tree. Testing a state machine coupled to an AnimationPlayer is annoying enough that I usually just don't. The real fix is pushing that logic out of nodes into plain RefCounted classes that don't extend Node, then testing those directly, but that requires the discipline to design it that way from the start, which I don't always have when I'm moving fast.

The rule I've landed on: write tests for anything with a formula or a data contract. Skip tests for anything fundamentally about node lifecycle or rendered output. And write at least one smoke test that boots a stripped-down scene and runs a critical player flow, not for coverage, just to catch "crashes on startup" regressions before they reach anyone else.

the thing that finally made testing actually stick for me was separating game logic from game context. once damage math, inventory queries, and save serialization are plain functions with zero node dependencies, GUT tests basically write themselves. the stuff that's genuinely hard to test (scene trees, physics, signals) usually doesn't need unit tests anyway, those are integration concerns. honestly if a "logic" class requires a Node to exist just to run, that's a design problem before it's a testing problem.

The framing that finally made testing click for me: stop trying to test systems, start testing decisions. I don't test "does the enemy AI state machine work". That's an integration concern with too much setup overhead. I test "given these inputs, does choose_action() return the right output."

Anything that takes game state as parameters and returns a deterministic result is a clean unit test candidate: damage formula, loot roll, pathfinding cost function, serialization round-trip. Anything that is game state (nodes, signals, scene trees) belongs in integration or playtest territory. Once you draw that line, what's actually testable becomes obvious and setup stops feeling like more work than it's worth.

What finally made this work for me was thinking in three buckets. Pure logic (damage formulas, inventory math, save serialization, anything with zero Node dependency) gets unit tests with GUT. It's actually easy because there's nothing to mock. Multi-system integration behaviors get a dedicated headless test scene where you can step through real game flow. Gameplay feel and timing, whether something actually feels right, that's playtesting.

The failure mode is trying to run everything through the same tool. Unit testing AI state transitions with mocked signals produces tests that are more brittle than the code they cover. Trying to playtest save file migration is its own nightmare. Match the approach to what you're validating and the whole thing becomes a lot less miserable.