Test a game before release
Use Code editor diagnostics, Run and a repeatable Studio test matrix.
Minimum developer loop
- Open your files in the full Studio Code editor and review TypeScript diagnostics.
- Choose Run and read Problems and Build output.
- Confirm that Preview is the latest build, not the last good build.
- Test gameplay in the actual host frame.
- Exercise unavailable and refused SDK outcomes.
- Test on a real phone if touch is declared.
- Submit a release and inspect its automatic checks.
Manual matrix
| Scenario | Expected result |
|---|---|
| Load and tap-to-play | No active gameplay or sound before the ready gate. |
| Pause, overlay and hidden tab | Simulation/input stop; audio is silent. |
| Resume after a menu or completed run | Game remains in the correct logical state. |
| Mute followed by pause/resume | Audio stays muted. |
| Resize and phone rotation | Controls remain reachable; canvas coordinates stay correct. |
| Save unavailable or full | No false success; recoverable state remains. |
| Signed-out score | Negative outcome handled without blocking gameplay. |
| Missing media | Useful error; no claim that loading succeeded. |
| End a run | One gameOver signal for that run. |
What previews cannot prove
Preview saves are in-memory and a new build gets a fresh store. Preview ads are simulations. Scores and sharing have different availability in preview and public play. Test public eligibility separately when a release is available.
Keep testing notes
Save a checkpoint before substantial changes. Record which preview or release you tested, the device, and the steps that failed. Use the SDK panel to simulate unavailable services and Console to investigate errors.
A successful build, a simulated service response and a real phone test provide different evidence. If the editor falls back to a plain text field, its full TypeScript diagnostics are unavailable.