Automatisiertes Game-Testing mit einer KI-IDE + Engine-MCP: Ein praktischer Weg

Automatisiertes Testen in Spielprojekten läuft normalerweise auf zwei Schienen: In-Repo-Unit-/Edit-Mode-Assertions und Checks, die Live-Engine-Kontext benötigen (Szenen, Prefabs, Hierarchie). Aufgezeichnete UI-Skripte brechen oft, wenn sich Layouts ändern. Ein robusterer Ansatz: Von einer KI-IDE (Cursor, Claude Code und ähnliche) aus Engine-MCP verwenden, damit das Modell den Szenenbaum, Komponenten und Skripte lesen und schreiben kann – so werden Testabsichten zu wiederholbaren Schritten.

Was automatisieren

Bevorzuge Arbeiten, die strukturiert, überprüfbar und im Diff reviewbar sind:

1. Strukturelle Smoke-Checks – Kritische Szenen laden; Player-/Enemy-Prefabs haben erforderliche Komponenten; UI-Wurzeln sind intakt
2. Konventionsprüfungen – Ordner und Benennung; keine tief hartcodierten Node-Pfade; öffentliche APIs und Signale sind noch vorhanden
3. Test-Gerüste – Unity Test Framework, Godot-Testszenen, Cocos-Unit-Test-Stubs
4. Erneute Checks nach Änderungen – Nach Gameplay-Änderungen dieselbe Checkliste gegen Szenen und Skripte erneut ausführen

Geräte-Farmen, tiefes Profiling und breites exploratives QA gehören weiterhin zu spezialisierten Tools und Personen. Der MCP-Pfad beschleunigt strukturierte, editorseitige Checks.

Empfohlener Weg

1. Absichten als Checkliste schreiben

Teile die Liste sowohl mit Menschen als auch mit dem Modell. Beispiele:

• Nach dem Laden der Hauptszene existiert Player mit aktivierter Bewegung
• Inventar startet geschlossen; wenn geöffnet, blockiert es die Welteingabe
• Enemy-Prefab hat Collider + Health, mit erforderlichen Signalen/Events verdrahtet

Halte sie in Repo-Dokumenten wie TESTING.md und entwickle sie mit dem Projekt weiter.

2. Engine-MCP verbinden

Installiere und starte MCP im Zielprojekt; verbinde dich von der KI-IDE über localhost. Anleitungen:

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

Halte Test-Helfer aus den ausgelieferten Player-Builds heraus.

3. Checks ausführen und Tests im Chat erstellen

Prompts sollten Pfade, Erwartungen und Einschränkungen enthalten:

Öffne die Hauptszene, liste die Hierarchie-Wurzeln; bestätige einen Player mit Move-/Health-Komponenten. Wenn fehlend, liste Lücken – erfinde nicht stillschweigend ein komplettes System.

Entwirf Test-Runner-Assertions für Inventar öffnen/schließen mit lesbaren Fehlermeldungen.

Das Modell inspiziert den Editor-Zustand über MCP und bearbeitet Test-Helfer; du reviewst Diffs, führst Tests lokal aus und mergst dann.

4. CI nach lokaler Stabilität einbinden

Bewährte Befehle (Unity Test Framework, Godot-Headless-Tests usw.) in CI einhängen. Verwende MCP auf dem Entwicklungsrechner, um diese Tests zu erstellen und zu pflegen; CI führt die Skripte im Repository für reproduzierbare Ergebnisse aus.

Kadenz

Absichtsliste → MCP-Read-only-Audit → Asserts generieren/aktualisieren → lokal grün → (optional) CI
        ↑______________________________________________|
              Erneut ausführen nach Gameplay- oder Szenenänderungen

Commite vor großen Änderungen. Wenn das Modell Testdateien berührt, beschränke es auf Pfade in der Checkliste, um Diffs klein zu halten.

Nächste Schritte

1. 5–10 Smoke-Absichten in TESTING.md aufnehmen
2. MCP für deine Engine verbinden; ein Read-only-Szenen-Audit ausführen
3. Erste Assertions erstellen, lokal bestehen, dann CI in Betracht ziehen

Auch nützlich: Godot MCP vs. manuelles Skripting, Unity MCP + Cursor-Workflow.