test-helpers

!bash "${CLAUDE_SKILL_DIR}/../../hooks/yaml-helper.sh" resolve_config --keys automation

Automation mode: Resolve modes.automation (project.local.yaml → project.yaml → default collaborative). Every AskUserQuestion call and every file write follows .claude/docs/automation-modes.md (collaborative asks always · guided major-only · autonomous logs and proceeds; automation_always_ask categories always prompt).

Test Helpers

Writing test cases is faster and more consistent when common setup, teardown, and assertion patterns are abstracted into helpers. This skill generates a tests/helpers/ library tailored to the project's actual engine, language, and systems — so every developer writes less boilerplate and more assertions.

Output: engine-specific helper files in the engine's helper root — the only place its test runner compiles them (.claude/docs/directory-structure.md):

tests/helpers/ below means the helper root for the project's engine.

When to run:

• After /test-setup scaffolds the framework (first time)
• When multiple test files repeat the same setup boilerplate
• When starting to write tests for a new system

Assertions: use the project's test framework, never bare assert()

Generated helpers must assert through the configured test framework's assertion API, resolved from testing.framework — not through GDScript's built-in assert().

Two things go wrong with a bare assert() in a helper, and both are silent:

1. It aborts the run instead of failing the test. A framework assertion records a failure and continues, so one broken expectation yields one red test. A bare assert() halts execution, so the first failure hides every result after it.
2. It is stripped in release builds. A helper library built on assert() stops asserting entirely in exactly the build you most want checked, and does so without any error — the tests still "pass".