test-helpers

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: tests/helpers/ directory with engine-specific helper files

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

---

1. Parse Arguments

Modes:

• /test-helpers [system-name] — generate helpers for a specific system (e.g., /test-helpers combat)
• /test-helpers all — generate helpers for all systems with test files
• /test-helpers scaffold — generate only the base helper library (no system-specific helpers); use this on first run
• No argument — run scaffold if no helpers exist, else all

---

2. Detect Engine and Language

Read .claude/docs/technical-preferences.md and extract:

• Engine: value
• Language: value
• Framework: from the Testing section

If engine is not configured: "Engine not configured. Run /setup-engine first."

---

3. Load Existing Test Patterns

Scan the test directory for patterns already in use:

Glob pattern="tests/**/*_test.*" (all test files)

For a representative sample (up to 5 files), read the test files and extract:

• Setup patterns (how before_each / setUp / fixtures are written)
• Common assertion patterns (what is being asserted most often)
• Object creation patterns (how game objects or scenes are instantiated in tests)
• Mock/stub patterns (how dependencies are replaced)

This ensures generated helpers match the project's existing style, not a generic template.

Also read:

• design/gdd/systems-index.md — to know which systems exist
• In-scope GDD(s) — to understand what data types and values need testing
• docs/architecture/tr-registry.yaml — to map requirements to tested systems