### Test Setup
Works with
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
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:
Fetches 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:
Restart Cursor to activate test-setup. Access via /test-setup in your agent's command palette.
We perform automated surface-level scans (Gen AI Scanner, Socket, Snyk) during installation. These checks detect common vulnerabilities but do not guarantee complete security. Always review skill source code and verify the publisher's reputation before production use.
Skills execute code in your environment. Always review source, verify the publisher, and test in isolation before production.
Submit your Claude Code skill and start earning
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
0
total installs
0
this week
10.7K
GitHub stars
0
upvotes
Run in your terminal
0
installs
0
this week
10.7K
stars
| 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.Prerequisites
Time Estimate
15-45 minutes depending on use case complexity
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.
JuliusBrussee/caveman
JuliusBrussee/caveman
whyashthakker/agent-skills-marketing
JuliusBrussee/caveman
whyashthakker/agent-skills-marketing
vercel-labs/skills
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