For gamedev, some regressions only show up when the game is actually running: broken player input, menu flows, pickups, or scene transitions. And as coding agents have gotten better at writing and maintaining tests, adding higher-level coverage has become practical. But I don’t found any e2e testing framework for godot right now.
So I built this to test my own games more reliably.
Showcase:
def test_player_moves(game):
start_x = game.get_property("/root/Main/Player", "position:x")
game.press_action("move_right")
game.wait_physics_frames(10)
end_x = game.get_property("/root/Main/Player", "position:x")
assert end_x > start_x
Details:
pytest and Godot run in separate processes and communicate over localhost TCP. Tests can trigger input actions, inspect or update nodes, call methods, and wait for frames or scene changes.
It works with the stock Godot engine and provides a synchronous Python API. The built-in fixtures support scene-reload and fresh-process isolation. When a test fails while the game is still responsive, the fixture captures a screenshot, and captured Godot logs are included in the pytest report.
Without --e2e, the autoload doesn’t open a socket or do any per-frame processing.
I also included an agent skill in the repository to help coding agents integrate the addon into an existing Godot project. The addon has also been submitted to the Godot Asset Library.
The project currently targets Godot 4.5+. I hope it’s useful to others too!
GitHub: godot-e2e
Why not use GUT or GDUnit and GDScript for it instead of Python? You’ve got three barriers. First, most people won’t know that they can benefits from automated testing. Then they need to learn it. Finally, they need to install and learn python to execute it.
I love to see more automated testing, but I recommend considering lowering barriers to entry. I’ve spent a 30 year career convincing professional software developers to do automated testing. I can tell you convincing people is hard enough without additional barriers.
1 Like
Thanks, and sorry for the late reply!
That’s a fair point — Python is definitely an extra dependency and an extra thing to learn.
My understanding is that GUT and GDUnit are great tools for testing from inside Godot, and they can absolutely cover more than small unit tests. What I wanted to explore with this project is a slightly different setup: running the test code outside Godot and treating the game as a separate process.
The runner launches a real Godot game, then drives it externally through a small TCP API — pressing actions, reading or changing node properties, calling methods, and waiting for frames or scene changes.
For me, it makes it easier to use a fresh Godot process for each test when I want stronger isolation, handle crashes or timeouts, and capture screenshots and logs when something fails.
So I don’t really see it as a replacement for GUT or GDUnit. They seem like a better fit for a lot of in-engine tests; this is more for cases where I want out-of-process, end-to-end coverage.
And yes, lowering the barrier matters. I haven’t found a simple way to write and run GDScript-based external tests without launching a Godot project/runtime anyway, which is why I went with Python and pytest. But I’m still thinking about ways to make the setup easier.
While installing python is trivial for a developer, especially since it comes pre=installed in many OSes these days, it is a huge barrier to entry for the average Godot user.