Test Setup
Automate repetitive workflows and reduce manual effort
Example: Generate reports, summarize documents, draft communications
Save 3-5 hours per week on routine tasks
Learn new skills, understand complex topics, get expert guidance
Example: Explain concepts, provide examples, suggest learning resources
Accelerate learning and skill development by 2x
Enhance output quality through reviews, suggestions, and refinements
Example: Review drafts, suggest improvements, catch errors
Improve work quality by 30-40% with less effort
Time estimate: 15-45 minutes depending on use case complexity
Prerequisites
Submit your Claude Code skill and start earning
epx add Donchitos/Claude-Code-Game-Studios --skill test-setupCompatible with
Supported agents
description: "Scaffold the test framework and CI/CD pipeline for the project's engine. Creates the tests/ directory structure, engine-specific test runner configuration, and GitHub Actions workflow. R
argument-hint: "[force]"
allowed-tools: Read, Glob, Grep, Bash, Write
| name | test-setup |
| description | "Scaffold the test framework and CI/CD pipeline for the project's engine. Creates the tests/ directory structure, engine-specific test runner configuration, and GitHub Actions workflow. Run once during Technical Setup phase before the first sprint begins." |
| argument-hint | "[force]" |
| user-invocable | true |
| allowed-tools | Read, Glob, Grep, Bash, Write |
This skill scaffolds the automated testing infrastructure for the project. It detects the configured engine, generates the appropriate test runner configuration, creates the standard directory layout, and wires up CI/CD so tests run on every push.
Run this once during the Technical Setup phase, before any implementation begins. A test framework installed at sprint start costs 30 minutes. A test framework installed at sprint four costs 3 sprints.
Output: tests/ directory structure + .github/workflows/tests.yml
Read engine config:
.claude/docs/technical-preferences.md and extract the Engine: value.[TO BE CONFIGURED]), stop:
"Engine not configured. Run /setup-engine first, then re-run /test-setup."Check for existing test infrastructure:
tests/ — does the directory exist?tests/unit/ and tests/integration/ — do subdirectories exist?.github/workflows/ — does a CI workflow file exist?tests/gdunit4_runner.gd (Godot) or tests/EditMode/ (Unity) or
Source/Tests/ (Unreal) for engine-specific artifacts.Report findings:
force argument was not passed:
"Test infrastructure appears to be in place. Re-run with /test-setup force
to regenerate. Proceeding will not overwrite existing test files."If the force argument is passed, skip the "already exists" early-exit and
proceed — but still do not overwrite files that already exist at a given path.
Only create files that are missing.
Based on the engine detected and the existing state, present a plan:
## Test Setup Plan — [Engine]
I will create the following (skipping any that already exist):
tests/
unit/ — Isolated unit tests for formulas, state, and logic
integration/ — Cross-system tests and save/load round-trips
smoke/ — Critical path test list (15-minute manual gate)
evidence/ — Screenshot and manual test sign-off records
README.md — Test framework documentation
[Engine-specific files — see per-engine details below]
.github/workflows/tests.yml — CI: run tests on every push to main
Estimated time: ~5 minutes to create all files.
Ask: "May I create these files? I will not overwrite any test files that already exist at these paths."
Do not proceed without approval.
After approval, create the following files:
tests/README.md# Test Infrastructure
**Engine**: [engine name + version]
**Test Framework**: [GdUnit4 | Unity Test Framework | UE Automation]
**CI**: `.github/workflows/tests.yml`
**Setup date**: [date]
## Directory Layout
tests/ unit/ # Isolated unit tests (formulas, state machines, logic) integration/ # Cross-system and save/load tests smoke/ # Critical path test list for /smoke-check gate evidence/ # Screenshot logs and manual test sign-off records
## Running Tests
[Engine-specific command — see below]
## Test Naming
- **Files**: `[system]_[feature]_test.[ext]`
- **Functions**: `test_[scenario]_[expected]`
- **Example**: `combat_damage_test.gd` → `test_base_attack_returns_expected_damage()`
## Story Type → Test Evidence
| Story Type | Required Evidence | Location |
|---|---|---|
| Logic | Automated unit test — must pass | `tests/unit/[system]/` |
| Integration | Integration test OR playtest doc | `tests/integration/[system]/` |
| Visual/Feel | Screenshot + lead sign-off | `tests/evidence/` |
| UI | Manual walkthrough OR interaction test | `tests/evidence/` |
| Config/Data | Smoke check pass | `production/qa/smoke-*.md` |
## CI
Tests run automatically on every push to `main` and on every pull request.
A failed test suite blocks merging.
### Engine-specific files
#### Godot 4 (`Engine: Godot`)
Create `tests/gdunit4_runner.gd`:
```gdscript
# GdUnit4 test runner — invoked by CI and /smoke-check
# Usage: godot --headless --script tests/gdunit4_runner.gd
extends SceneTree
func _init() -> void:
var runner := load("res://addons/gdunit4/GdUnitRunner.gd")
if runner == null:
push_error("GdUnit4 not found. Install via AssetLib or addons/.")
quit(1)
return
var instance = runner.new()
instance.run_tests()
quit(0)
Create tests/unit/.gdignore_placeholder with content:
# Unit tests go here — one subdirectory per system (e.g., tests/unit/combat/)
Create tests/integration/.gdignore_placeholder with content:
# Integration tests go here — one subdirectory per system
Note in the README: Installing GdUnit4
1. Open Godot → AssetLib → search "GdUnit4" → Download & Install
2. Enable the plugin: Project → Project Settings → Plugins → GdUnit4 ✓
3. Restart the editor
4. Verify: res://addons/gdunit4/ exists
Engine: Unity)Create tests/EditMode/ placeholder file tests/EditMode/README.md:
# Edit Mode Tests
Unit tests that run without entering Play Mode.
Use for pure logic: formulas, state machines, data validation.
Assembly definition required: `tests/EditMode/EditModeTests.asmdef`
Create tests/PlayMode/README.md:
# Play Mode Tests
Integration tests that run in a real game scene.
Use for cross-system interactions, physics, and coroutines.
Assembly definition required: `tests/PlayMode/PlayModeTests.asmdef`
Note in the README: Enabling Unity Test Framework
Window → General → Test Runner
(Unity Test Framework is included by default in Unity 2019+)
Engine: Unreal or Engine: UE5)Create Source/Tests/README.md:
# Unreal Automation Tests
Tests use the UE Automation Testing Framework.
Run via: Session Frontend → Automation → select "MyGame." tests
Or headlessly: UnrealEditor -nullrhi -ExecCmds="Automation RunTests MyGame.; Quit"
Test class naming: F[SystemName]Test
Test category naming: "MyGame.[System].[Feature]"
Create .github/workflows/tests.yml:
name: Automated Tests
on:
push:
branches: [main]
pull_request:
branches: [main]
jobs:
test:
name: Run GdUnit4 Tests
runs-on: ubuntu-latest
steps:
- name: Checkout
uses: actions/checkout@v4
with:
lfs: true
- name: Run GdUnit4 Tests
uses: MikeSchulze/gdUnit4-action@v1
with:
godot-version: '[VERSION FROM docs/engine-reference/godot/VERSION.md]'
paths: |
tests/unit
tests/integration
report-name: test-results
- name: Upload Test Results
if: always()
uses: actions/upload-artifact@v4
with:
name: test-results
path: reports/
Create .github/workflows/tests.yml:
name: Automated Tests
on:
push:
branches: [main]
pull_request:
branches: [main]
jobs:
test:
name: Run Unity Tests
runs-on: ubuntu-latest
steps:
- name: Checkout
uses: actions/checkout@v4
with:
lfs: true
- name: Run Edit Mode Tests
uses: game-ci/unity-test-runner@v4
env:
UNITY_LICENSE: ${{ secrets.UNITY_LICENSE }}
with:
testMode: editmode
artifactsPath: test-results/editmode
- name: Run Play Mode Tests
uses: game-ci/unity-test-runner@v4
env:
UNITY_LICENSE: ${{ secrets.UNITY_LICENSE }}
with:
testMode: playmode
artifactsPath: test-results/playmode
- name: Upload Test Results
if: always()
uses: actions/upload-artifact@v4
with:
name: test-results
path: test-results/
Note: Unity CI requires a UNITY_LICENSE secret. Add to GitHub repository
secrets before the first CI run.
Create .github/workflows/tests.yml:
name: Automated Tests
on:
push:
branches: [main]
pull_request:
branches: [main]
jobs:
test:
name: Run UE Automation Tests
runs-on: self-hosted # UE requires a local runner with the editor installed
steps:
- name: Checkout
uses: actions/checkout@v4
with:
lfs: true
- name: Run Automation Tests
run: |
"$UE_EDITOR_PATH" "${{ github.workspace }}/[ProjectName].uproject" \
-nullrhi -nosound \
-ExecCmds="Automation RunTests MyGame.; Quit" \
-log -unattended
shell: bash
- name: Upload Logs
if: always()
uses: actions/upload-artifact@v4
with:
name: test-logs
path: Saved/Logs/
Note: UE CI requires a self-hosted runner with Unreal Editor installed.
Set the UE_EDITOR_PATH environment variable on the runner.
Create tests/smoke/critical-paths.md:
# Smoke Test: Critical Paths
**Purpose**: Run these 10-15 checks in under 15 minutes before any QA hand-off.
**Run via**: `/smoke-check` (which reads this file)
**Update**: Add new entries when new core systems are implemented.
## Core Stability (always run)
1. Game launches to main menu without crash
2. New game / session can be started from the main menu
3. Main menu responds to all inputs without freezing
## Core Mechanic (update per sprint)
<!-- Add the primary mechanic for each sprint here as it is implemented -->
<!-- Example: "Player can move, jump, and the camera follows correctly" -->
4. [Primary mechanic — update when first core system is implemented]
## Data Integrity
5. Save game completes without error (once save system is implemented)
6. Load game restores correct state (once load system is implemented)
## Performance
7. No visible frame rate drops on target hardware (60fps target)
8. No memory growth over 5 minutes of play (once core loop is implemented)
After writing all files, report:
Test infrastructure created for [engine].
Files created:
- tests/README.md
- tests/unit/ (directory)
- tests/integration/ (directory)
- tests/smoke/critical-paths.md
- tests/evidence/ (directory)
[engine-specific files]
- .github/workflows/tests.yml
Next steps:
1. [Engine-specific install step, e.g., "Install GdUnit4 via AssetLib"]
2. Write your first test: create tests/unit/[first-system]/[system]_test.[ext]
3. Run `/qa-plan sprint` before your first sprint to classify stories and set
test evidence requirements
4. `/smoke-check` before every QA hand-off
Gate note: /gate-check Technical Setup → Pre-Production now requires:
- tests/ directory with unit/ and integration/ subdirectories
- .github/workflows/tests.yml
- At least one example test file
Run /test-setup and write one example test before advancing.
Verdict: **COMPLETE** — test framework scaffolded and CI/CD wired up.
/setup-engine. Do not guess.force flag skips the "already exists" early-exit but never overwrites.
It means "create any missing files even if the directory already exists."UNITY_LICENSE secret must be configured
manually. Do not attempt to automate license management.AI-first code editor with Composer
Before installing skills in Cursor, ensure your development environment meets these requirements:
node --versiontest-setupExecute the skills CLI command in your project's root directory to begin installation:
epx add Donchitos/Claude-Code-Game-Studios --skill test-setupFetches test-setup from Donchitos/Claude-Code-Game-Studios and configures it for Cursor.
The CLI shows a list of agents. Use arrow keys and space to select Cursor:
Confirm successful installation by checking the skill directory location:
.cursor/skills/test-setup
Restart Cursor to activate test-setup. Access via /test-setupin your agent's command palette.
Learn more:View source on GitHubSkills CLI docsAbout CursorWhat are agent skills?
Steps
Common Pitfalls
✓ Do
✗ Don't
💡 Pro Tips
✓ Use when
Use when skill capabilities match your task, clear ROI on time saved, and you can validate outputs. Best for repetitive tasks, learning, and quality improvement.
✗ Avoid when
Avoid when task requires deep expertise you can't validate, involves sensitive decisions, or when learning process is more valuable than speed of completion.
balance-check
Donchitos/Claude-Code-Game-Studios · Game QA & Testing · same repo
regression-suite
Donchitos/Claude-Code-Game-Studios · Game QA & Testing · same repo
architecture-decision
Donchitos/Claude-Code-Game-Studios · Game Dev Planning · same repo
onboard
Donchitos/Claude-Code-Game-Studios · Game Dev Planning · same repo
security-audit
Donchitos/Claude-Code-Game-Studios · Game Dev Code · same repo
create-architecture
Donchitos/Claude-Code-Game-Studios · Game Dev Planning · same repo
test-setup has been reliable in day-to-day use. Documentation quality is above average for community skills.
test-setup is among the better-maintained entries we tried; worth keeping pinned for repeat workflows.
Keeps context tight: test-setup is the kind of skill you can hand to a new teammate without a long onboarding doc.
test-setup reduced setup friction for our internal harness; good balance of opinion and flexibility.
Useful defaults in test-setup — fewer surprises than typical one-off scripts, and it plays nicely with `npx skills` flows.
Solid pick for teams standardizing on skills: test-setup is focused, and the summary matches what you get after install.
test-setup has been reliable in day-to-day use. Documentation quality is above average for community skills.
Solid pick for teams standardizing on skills: test-setup is focused, and the summary matches what you get after install.
test-setup reduced setup friction for our internal harness; good balance of opinion and flexibility.
Registry listing for test-setup matched our evaluation — installs cleanly and behaves as described in the markdown.
showing 1-10 of 55