Install Godot Gdscript Headless Testing
Pick your agent. Every command is ready to paste.
npx skills add gamedev-skills/awesome-gamedev-agent-skills --skill godot-gdscript-headless-testingThe open skills CLI detects your agents (Claude Code, Cursor, Codex and 70+ more) and installs to the right folder. Add -g to install globally.
01
Install it
Run the command above, or upload the folder in Claude.
02
Ask naturally
Describe the task. Your agent loads godot-gdscript-headless-testing when the request matches its description.
03
Name it if needed
If it does not trigger, say “use the godot-gdscript-headless-testing skill”. In Codex, type $godot-gdscript-headless-testing.
The skill itself
SKILL.md
Godot GDScript headless testing (4.x)
Run GDScript tests from the command line, without the editor GUI, and get a real process exit code CI can act on. Targets Godot 4.7 headless CLI.
When to use
- Use when a Godot project has no testing addon installed and needs a fast way to verify GDScript logic (pure functions, resource loading, autoload state) from a terminal or CI pipeline.
- Use when wiring a CI job that must fail the build when a
.gdtest fails. - Use when debugging why a
godot --headlessinvocation hangs, opens a window, or exits 0 despite failing assertions.
When not to use: GDScript syntax or language features themselves →
godot-gdscript; export/build pipeline and platform templates → godot-export
(its own --headless use case, producing a binary, not running tests).
Workflow
- Confirm the binary resolves headless. Godot 4.x ships
--headlessbuilt in (no export template needed); rungodot --headless --versionand confirm it prints a version string, not a GUI window. - On a fresh checkout, import before running tests.
.godot/is normally not committed, so a clean checkout has no import cache:class_nametypes fail to resolve (Identifier "X" not declared in the current scope) and imported assets fail to load (No loader found for resource: res://...). Rungodot --headless --path <project_dir> --importonce first, in CI and locally. - Write the runner as a
SceneTreescript, not aNodescene. ASceneTreescript's_initialize()runs once before any frame — enough for pure-logic tests and no.tscnrequired to launch. - Track pass/fail counts yourself and call
quit(<code>)explicitly. Do not use bareassert()to fail a test. Godot does not turn the process exit code non-zero onpush_error()by itself — the runner must count failures and callquit(1). Worse, a failedassert()inside_initialize()(official/debug build) printsSCRIPT ERROR: Assertion failedand stops execution beforequit()runs, so the process never exits and CI hangs until its own timeout. Use anassert_eq()-style helper that records the failure and keeps going. - Invoke with
godot --headless --path <project_dir> --script res://<runner>.gdand read the process exit code, not just stdout, from the shell or CI step.--scriptaccepts both ares://-relative path and an absolute filesystem path (e.g. a runner outside the project folder); either works. - Redirect stdout and stderr to files when scripting the invocation from a
wrapper shell (PowerShell, some CI runners).
push_error()output goes to stderr and can be dropped or reordered when only stdout is captured live. - Add a step timeout in CI. Even with the
assert()pitfall avoided, anawaitthat never resolves (Pattern #2) hangs the runner forever; atimeout-minuteson the CI step is a backstop CI-side, not a substitute for backing everyawaitwith a timeout node.
Patterns
1. Minimal SceneTree test runner with a real exit code
# res://test_runner.gd — run with:
# godot --headless --path . --script res://test_runner.gd
extends SceneTree
var passed := 0
var failed := 0
func _initialize() -> void:
test_add()
print("Results: %d passed, %d failed" % [passed, failed])
quit(1 if failed > 0 else 0) # non-zero exit fails the CI step
func assert_eq(actual, expected, label: String) -> void:
if actual == expected:
passed += 1
else:
failed += 1
push_error("FAIL %s: expected %s, got %s" % [label, expected, actual])
func test_add() -> void:
assert_eq(2 + 2, 4, "test_add")
Verified against Godot 4.7.2: godot --headless --path . --script res://test_runner.gd prints Results: N passed, M failed to stdout, routes
push_error lines to stderr, and returns process exit code 0 when
failed == 0, 1 otherwise.
2. Testing something that needs a frame, a timer, or a signal
extends SceneTree
var passed := 0
var failed := 0
func _initialize() -> void:
await run_tests()
print("Results: %d passed, %d failed" % [passed, failed])
quit(1 if failed > 0 else 0) # track and report failures here too
func assert_eq(actual, expected, label: String) -> void:
if actual == expected:
passed += 1
else:
failed += 1
push_error("FAIL %s: expected %s, got %s" % [label, expected, actual])
func run_tests() -> void:
# `root` is not inside the tree yet during _initialize(): a Timer started now
# errors ("not inside the tree") and its `timeout` never fires. Wait one frame.
await process_frame
var timer_node := Timer.new()
timer_node.one_shot = true # default Timer restarts after timeout
root.add_child(timer_node)
timer_node.start(0.1)
await timer_node.timeout
# assertions here can rely on the node having been in the tree for a frame
assert_eq(timer_node.is_stopped(), true, "timer_fires_once")
timer_node.queue_free()
_initialize() may await, which is what makes this pattern work for anything
that needs a node to actually enter the tree, a timer to fire, or a signal to
emit — none of which happen before the engine has processed at least one frame.
Use the same passed/failed counter and assert_eq() helper as Pattern #1;
a version of this pattern that always calls quit(0) can never fail a build.
3. CI step (GitHub Actions) that gates on the exit code
- name: Import project (populates .godot/ on a fresh checkout)
run: godot --headless --path . --import
- name: Run GDScript tests
timeout-minutes: 5
run: godot --headless --path . --script res://test_runner.gd
The import step is required on a clean checkout — without it, class_name types
and imported resources fail to resolve. No extra flag is needed for the test
step itself: the runner already fails the job on a non-zero exit code from
run:; the discipline lives in the runner script's quit() call, not in the CI
configuration. timeout-minutes is a backstop against a hung await (see
Pitfalls), not a substitute for backing every await with a timeout node.
Pitfalls
Script "does nothing" or opens the editor window → missing
--headless, or the script path is wrong.--scriptaccepts ares://-relative path resolved against--path <project_dir>, and also an absolute filesystem path — both work.Identifier "X" not declared in the current scope, or a resource fails to load, only on a fresh checkout →.godot/(the import cache) is normally not committed, soclass_nametypes and imported assets aren't resolved yet. Rungodot --headless --path <project_dir> --importonce before the test step.A failed
assert()hangs instead of failing the test → in an official/debug build, a failedassert()inside_initialize()printsSCRIPT ERROR: Assertion failedand stops that function before it reachesquit()— the process never exits and CI waits until its own timeout. Use anassert_eq()counter (Pattern #1) instead of bareassert()in test runners.Exit code stays 0 despite failed assertions → the runner never called
quit(1), or (Pattern #2) it always callsquit(0)regardless of failures. Track failures yourself and callquit()explicitly with a code that reflects them; do not rely onassert()orpush_error()alone to change the exit code.A test that hits a runtime error is silently skipped and the run still exits 0 → an error such as calling a method on
nullprintsSCRIPT ERRORand aborts only that test function; the runner carries on, nothing was counted as failed, andquit(0)runs. Declare tests-> bool, end each withreturn true, and count anything else as a failure — an aborted function hands its caller a default value instead (await call(t)works the same for tests thatawait):for t: String in ["test_add", "test_load"]: if call(t) != true: failed += 1 push_error("FAIL %s: did not finish (runtime error?)" % t)_initialize()runs before nodes, timers, or signals exist → logic that needs a frame to have processed mustawaita signal or a timer before asserting; see Pattern #2.rootitself is not inside the tree yet, so aTimeradded and started there errors and itstimeoutnever fires (the runner hangs) —await process_framefirst.Output looks empty or out of order from a wrapper shell → some shells (PowerShell in particular) can reorder or drop a native process's live stdout/stderr. Redirect both streams to files and read the files after the process exits, instead of trusting the live console.
Runner never terminates → a
SceneTreescript keeps running until something callsquit(). A test thatawaits a signal that never fires hangs the job forever — always back anawaitwith a timeout node as a fallback, and settimeout-minuteson the CI step as a backstop.
Related skills
godot-gdscript— the language syntax and node lifecycle this pattern's runner script itself uses.godot-export— headless CLI export/build, a different--headlessuse case.
Tips for Godot Gdscript Headless Testing
- • Start a fresh session after installing so your agent picks up the new skill.
- • It is part of a pack with 40 skills. Install only the ones you need with --skill to keep triggers precise.
- • If two skills overlap, mention the one you want by name.
Questions about Godot Gdscript Headless Testing
What does the Godot Gdscript Headless Testing skill do?
Run GDScript test suites from the command line with `godot --headless`, using a SceneTree/MainLoop runner script that exits non-zero on failure so CI can gate merges. Use when a Godot project needs unit tests without opening the editor, when wiring a CI job (GitHub Actions or similar) that must fail the build on a failing `.gd` test, or when a `godot --headless` invocation hangs, opens a window, or exits 0 despite failed assertions.
How do I install Godot Gdscript Headless Testing?
Run "npx skills add gamedev-skills/awesome-gamedev-agent-skills --skill godot-gdscript-headless-testing" in your project. The skills CLI installs it for Claude Code, Cursor, Codex and 70+ other agents. In Claude on the web, upload the skill folder as a ZIP under Customize > Skills.
Does Godot Gdscript Headless Testing work in Cursor and Codex?
Yes. Godot Gdscript Headless Testing uses the open SKILL.md format, so it works in Claude Code, Claude, Cursor, OpenAI Codex, Gemini CLI, GitHub Copilot and other agents that support agent skills.
Is Godot Gdscript Headless Testing free?
Godot Gdscript Headless Testing is open source on GitHub under the Apache-2.0 license. It is free to install; check the license before commercial use.
Who made Godot Gdscript Headless Testing?
Godot Gdscript Headless Testing is published by gamedev-skills in the gamedev-skills/awesome-gamedev-agent-skills repository, together with 39 other skills.



