Skip to main content

Testing with the Simulator

Run a build in the Simulator​

The Simulator is a tool in the Developer Console that runs your game in a framed preview and plays the role of Jest.com for it. The SDK is handled by a mock host, so player identity, purchases, notifications, and other platform calls are answered locally.

Use it when you want a clean, full-viewport surface to:

  • Record a self-review attached to a specific version so moderators can watch a real play-through during review.
  • Drive a build (or a local URL) end-to-end with a checklist that flags common issues before you submit.

The Simulator is reachable from the left sidebar (Simulator) and from the Self Review action on each version in a game's Versions tab.

Record a self-review​

A self-review is a recorded play-through of a specific version. Moderators watch it during game review, alongside the build itself.

  1. Open your game's Versions tab in the Developer Console.
  2. Next to the version you want to submit, select Self Review. The Simulator opens in record mode for that version.
  3. Select Record and grant the browser's screen-capture prompt for the current tab.
  4. Play through your game. The Simulator captures both the iframe and any overlays (login, purchase, loading screen) at the tab level.
  5. When you're done, select Stop & Save. A short form appears where you can add notes for the moderator, then save.

Saved self-reviews are listed under the version in the Versions tab and appear in the moderation view for that version.

Good for​

  • Giving moderators evidence that a version's core flows actually work end-to-end before they review it manually
  • Capturing reproducible play-throughs to attach context (notes) to specific builds
  • Catching regressions in your own flows by replaying saved sessions across versions

Not good for​

  • Demonstrating real platform behavior — login, purchases, and notifications are mocked, not live (use sandbox users for that)
  • Performance or timing measurements — the Simulator runs in a framed container with a mocked host, not the real Jest.com shell

Drive any URL​

In URL mode, the Simulator loads any URL you give it — including http://localhost:<port> — instead of an uploaded build. Recording is disabled in this mode; it is meant for ad-hoc test-drives.

  1. Open the Simulator from the sidebar.
  2. Keep the mode toggle on URL.
  3. Paste your URL (for example http://localhost:3000/g/my-game?host=http://localhost:3000) and select Load.

This works against a running local dev server, so you can iterate on your game and reload the Simulator manually to see changes. There is no auto-refresh today — if your dev server hot-reloads the game itself, that still works inside the iframe; changes that require re-running SDK initialization need a Simulator reload.

If your local server sets X-Frame-Options: DENY or a restrictive frame-ancestors, the iframe will refuse to load. Adjust the dev server config to allow framing during development.

Good for​

  • Trying out a local build against the Simulator's mocked host (products, player data, entry payload) without uploading
  • Exercising the checklist against changes you haven't shipped yet
  • Sharing a repeatable test harness across developers without each person needing a sandbox user

Not good for​

  • Testing inside the real Jest.com shell — use the hosted emulator for that
  • Validating an uploaded build with a live platform — use sandbox users
  • Day-to-day local iteration where the in-game JestSDK debug menu is enough — use local mocks

Reading the checklist​

The Simulator evaluates a set of rules against the SDK activity it observes. Each rule has one of four states:

  • Pass — the rule saw what it expected.
  • Warn — not broken, but worth improving (for example, all notifications use the same body, or bodies contain emoji that may not render on SMS).
  • Fail — a clear problem that will block review (for example, logging in an already-registered player, or never calling GetIncompletePurchases after a meaningful amount of startup traffic).
  • Waiting — the rule has not seen enough activity to judge yet. This is the default before you exercise the relevant flow and is not a failure on its own.

Rules cover four areas: user management (SDK initialization, login, guest data), notifications (scheduling window, customization, asset references, body length, charset), purchases (catalog fetch, purchase start, recovering incomplete purchases), and referrals.

The checklist is a guide, not a gate. Some rules remain in Waiting for legitimate reasons — for example, the recovered-purchase rule stays in "Waiting" unless you enable seeded incomplete purchases in the config panel and exercise the flow.

Configure the mocked host​

The Simulator's right-hand Config panel lets you set up mocked platform state for the session:

  • Player — toggle registration, edit username/avatar, log out to restart as a guest.
  • Entry payload — edit the payload the game receives on startup. Changes reload the iframe so the game re-runs initialization.
  • Player data — pre-seed player data, or pull the current in-game state into the editor with Use live state.
  • Notification assets — register known asset references so the checklist can validate them.
  • Purchases — configure products, choose canned responses for BeginPurchase / CompletePurchase, toggle seeded incomplete purchases for recovery testing.
  • Referrals — seed referral entries for GetReferrals.

Everything in the Config panel is in-session only. Nothing here writes back to the platform.