Automated Game Testing with an AI IDE + Engine MCP: A Practical Path

Automated testing in game projects usually runs on two tracks: in-repo unit / edit-mode assertions, and checks that need live engine context (scenes, prefabs, hierarchy). Recorded UI scripts often break when layouts change. A more durable approach: from an AI IDE (Cursor, Claude Code, and similar), use engine MCP so the model can read and write the scene tree, components, and scripts—turning test intents into repeatable steps.

What to automate

Favor work that is structured, assertable, and reviewable in diff:

1. Structural smoke — critical scenes load; player/enemy prefabs have required components; UI roots are intact
2. Convention audits — folders and naming; no deep hard-coded node paths; public APIs and signals still present
3. Test scaffolding — Unity Test Framework, Godot test scenes, Cocos unit-test stubs
4. Post-change rechecks — after gameplay edits, re-run the same checklist against scenes and scripts

Device farms, deep profiling, and broad exploratory QA still belong to specialist tools and people. The MCP path speeds up structured, editor-side checks.

Recommended path

1. Write intents as a checklist

Share the list with both humans and the model. Examples:

• After main scene load, Player exists with movement enabled
• Inventory starts closed; when open, it blocks world input
• Enemy prefab has collider + health, with required signals/events wired

Keep it in repo docs such as TESTING.md and evolve it with the project.

2. Connect engine MCP

Install and start MCP in the target project; connect from the AI IDE over localhost. Guides:

• Unity MCP
• Godot MCP
• Cocos Creator: 3.x · 2.x

Keep test helpers out of shipping player builds.

3. Run checks and scaffold tests in chat

Prompts should include paths, expectations, and constraints:

Open the main scene, list Hierarchy roots; confirm a Player with move/health components. If missing, list gaps—do not silently invent a full system.

Draft Test Runner assertions for inventory open/close with readable failure messages.

The model inspects editor state via MCP and edits test helpers; you review diffs, run tests locally, then merge.

4. Wire CI after local stability

Hook proven commands (Unity Test Framework, Godot headless tests, etc.) into CI. Use MCP on the development machine to author and maintain those tests; CI runs the scripts in the repository for reproducible results.

Cadence

Intent list → MCP read-only audit → generate/update asserts → local green → (optional) CI
        ↑______________________________________________|
              Re-run after gameplay or scene changes

Commit before large edits. When the model touches test files, constrain it to paths in the checklist to keep diffs small.

Next steps

1. Put 5–10 smoke intents in TESTING.md
2. Connect MCP for your engine; run one read-only scene audit
3. Scaffold the first assertions, pass them locally, then consider CI

Also useful: Godot MCP vs manual scripting, Unity MCP + Cursor workflow.