Godot Testing

Godot Testing

This skill covers test-driven development (TDD) for Godot 4.3+ projects using GUT (Godot Unit Testing) and gdUnit4. It includes framework selection, full RED-GREEN-REFACTOR examples, test structure, running tests in CI, and common testing patterns.

Related skills: godot-code-review for review checklists, dependency-injection for test-friendly architecture, export-pipeline for CI/CD test automation.

Framework Selection

Rule of thumb: Use GUT for GDScript-only projects. Use gdUnit4 for C# projects or when you need first-class C# support and scene runner utilities.

TDD Workflow: RED-GREEN-REFACTOR

The standard Test-Driven Development cycle: write a failing test (RED), write minimal code to pass (GREEN), then refactor without breaking the test. Each step has its own discipline — don't skip RED (you'll write tests that pass trivially), and don't skip REFACTOR (technical debt compounds).

See references/tdd-workflow.md for a worked GDScript + C# example walking through all three steps on a HealthComponent.

Test Directory Structure

Copy code
res://
├── src/
│   └── components/
│       ├── health_component.gd
│       └── HealthComponent.cs
└── tests/
    ├── unit/
    │   ├── test_health_component.gd      # GUT: test_ prefix required
    │   └── HealthComponentTest.cs        # gdUnit4 C#: [TestSuite] attribute
    ├── integration/
    │   ├── test_player_scene.gd
    │   └── PlayerSceneTest.cs
    └── gut_config.json                   # GUT configuration (optional)

Naming conventions

Running Tests

Both frameworks ship a CLI runner. GUT: addons/gut/gut_cmdln.gd invoked via godot --headless --path . -s addons/gut/gut_cmdln.gd. gdUnit4: --add-gdunit-test-runner argument, or via the editor "GdUnit Tests" dock. CI: tag-triggered or PR-triggered GitHub Action that installs Godot, runs the suite, exits non-zero on failure.

See references/running-tests.md for full GUT and gdUnit4 CLI invocations + a copy-pasteable GitHub Actions workflow.

Testing Patterns

Four common patterns: scenes with nodes (instantiate via add_child in before_each, free in after_each), signal testing (assert that emitting works and connect-then-emit fires), mocking/doubling (gdUnit4 Mock<T> or hand-rolled fakes via @export injection), async (await yields, signals, frames in tests).

See references/testing-patterns.md for full code on each pattern (GDScript + C# where applicable).

Common Assertions

GUT assertions

gdUnit4 assertions (GDScript + C#)

What NOT to Test

Avoid testing things that add noise without catching real bugs:

• Godot engine internals — do not assert that Node.add_child() works or that @export variables show up in the editor
• Private implementation details — test behavior through the public API; if a refactor breaks a test that covers only private state, the test is wrong
• Visual/rendering output — pixel-level rendering results are brittle; test the data driving the visuals instead
• Timing-sensitive floats without margins — use assert_almost_eq / IsApproximately for physics values
• One-liners that wrap a built-in — a property getter that just returns a field needs no test
• Every possible invalid input — test the documented contract, not every imaginable misuse

Checklist

• Each test file matches the naming convention for the chosen framework (test_*.gd / *Test.cs)
• Tests extend the correct base class (GutTest / GdUnit4.GdUnitTestSuite)
• Nodes added to the scene tree use add_child_autofree or auto_free — never manual queue_free()
• Signals are watched before the action that triggers them
• Mocks/doubles are used for external dependencies, not for the unit under test
• Each test covers exactly one behavior (one logical assertion per test)
• CI workflow runs tests headlessly on every push and PR
• Flaky async tests use explicit timeouts, not arbitrary sleep durations
• Tests pass before merging (RED is only acceptable while actively implementing)