@seriousgaming/sdk-tools 0.0.0-stage → 1.0.0-alpha.1

package/dist/docs/guides/engine-testing.md

@@ -0,0 +1,477 @@
+# Engine testing
+
+Test your whole game in-process: no dev server, no browser, and no LLM API key required, because service callbacks are stubbed by default.
+
+## What you'll learn
+
+- What `createTestSession` is and when to use it
+- How engine tests fit alongside unit tests and Playwright tests
+- How to write engine tests: ticking, asserting context, injecting decisions
+- How to test hooks, validators, endpoints, undo and timers
+- How service callbacks are stubbed, and how to override them or reach the platform
+- How to move a test from `GameRunner`, which has been removed
+
+## What is createTestSession?
+
+`createTestSession` starts the session the dev server runs, inside your test process. Everything a game does is there: `Init` and `Run`, hooks when somebody joins, validators on a participant's write, endpoints, undo, independent teams ticking on their own, the configuration step, and automatic ticks. You drive it with the same commands the console, the CLI and your surfaces send, and read it with the same state `sdk view --full` prints.
+
+```typescript
+import { fileURLToPath } from 'url';
+
+import { createTestSession } from '@seriousgaming/sdk-tools/client';
+
+const session = await createTestSession({
+    packagePath: fileURLToPath(new URL('../..', import.meta.url)),
+});
+
+await session.send({ type: 'tick' });
+const team = session.state().teams[0];
+
+await session.close();
+```
+
+### Which runtime version your tests execute
+
+`createTestSession` runs a copy of the SDK runtime that is compiled into
+`@seriousgaming/sdk-tools` when that package is built, not
+the `@seriousgaming/sdk` you have installed. Upgrading one
+without the other therefore changes nothing about how your engine executes, so
+keep the two on the same version and treat the tools version as the one that
+decides behaviour. It also means that if you are narrowing down a defect by
+changing versions, only the tools version is a variable.
+
+## The three testing layers
+
+Engine tests sit between unit tests and Playwright tests:
+
+| Layer      | Tool              | Tests                                                               | Speed   | Needs       |
+| ---------- | ----------------- | ------------------------------------------------------------------- | ------- | ----------- |
+| Unit       | Vitest (jsdom)    | Individual Init/Run functions, React components                     | ~1s     | Nothing     |
+| **Engine** | **Vitest (node)** | **The whole game: ticks, decisions, hooks, validators, completion** | **~1s** | **Nothing** |
+| Browser    | Playwright        | UI rendering, user input, iframe communication                      | ~30s+   | Dev server  |
+
+**When a Playwright test fails**, run engine tests first to isolate the problem:
+
+- Engine test fails → bug is in your game logic
+- Engine test passes → bug is in your UI component or iframe communication
+
+## Setup
+
+When you create a package with `sdk new package`, the engine test scaffold is included automatically:
+
+```
+testing/engine/game.engine.test.ts   ← starter engine test
+vitest.engine.config.ts              ← node environment config
+```
+
+And your `package.json` includes:
+
+```json
+"test:engine": "vitest run --config vitest.engine.config.ts"
+```
+
+For an existing project, see the [Engine Testing recipe](../recipes/test-with-engine.md).
+
+## Writing engine tests
+
+### Basic structure
+
+```typescript
+// testing/engine/game.engine.test.ts
+import { fileURLToPath } from 'url';
+
+import { createTestSession, type TestSession } from '@seriousgaming/sdk-tools/client';
+import { afterEach, beforeEach, describe, expect, it } from 'vitest';
+
+import type { Context, SharedContext } from '../../engine/types';
+
+const PACKAGE_PATH = fileURLToPath(new URL('../..', import.meta.url));
+
+describe('mygame', () => {
+    let session: TestSession<Context, SharedContext>;
+
+    beforeEach(async () => {
+        session = await createTestSession<Context, SharedContext>({ packagePath: PACKAGE_PATH });
+    });
+
+    afterEach(async () => {
+        await session.close();
+    });
+
+    it('initialises with expected defaults', () => {
+        expect(session.team(0).context.main).toEqual({ Delta: 0, Total: 0 });
+    });
+});
+```
+
+The two type parameters are the engine's generated `Context` and `SharedContext`. They type what `state()`, `team()` and `shared` return and what `setData` and `setSharedData` accept, so a test reads `session.team(0).context.main.Total` with no cast. Nothing checks them against the package, as nothing checks a cast; leave them out and the contexts are untyped records. A game whose hooks keep capabilities the engine does not declare can intersect their `Context` types too.
+
+`beforeEach` starts a fresh session for every test, and `afterEach` stops its timers. Nothing is read from or written to `.seriousgaming-sdk/`, so there are no files to clean up, and a test does not depend on what you last ran `sdk configure` with.
+
+### Ticking and asserting
+
+`tick()` ticks as the facilitator does, and answers with how it settled. A tick that succeeds is `{ ok: true }`; one the session refuses, such as a tick past the game's limit, is `{ ok: false, outcome }`. A refusal is an answer, not a throw, so a test can assert on it:
+
+```typescript
+it('adds Delta to Total on each tick', async () => {
+    await session.setData(0, { main: { Delta: 5 } });
+
+    expect(await session.tick()).toEqual({ ok: true, committedAtTick: 1 });
+
+    expect(session.state().session.completedTicks).toBe(1);
+    expect(session.team(0).context.main.Total).toBe(5);
+});
+```
+
+Every helper is a command underneath, and `send` takes any command directly: `session.tick()` is `session.send({ type: 'tick' })`.
+
+`state()` is the whole session: `session.completedTicks`, `session.complete`, every team with its `context`, `completedTicks` and `participants`, the shared store, the timer and `settings`, every settings resource's resolved values keyed by identifier.
+
+### A note on `instanceof` and engine-produced values
+
+Engine logic is evaluated in its own JavaScript environment, matching the
+production runtime. Values it builds therefore answer `instanceof` and
+`toBeInstanceOf` against that environment's constructors, not your test file's,
+so an assertion written this way can fail on a value that is perfectly correct:
+
+```typescript
+// Fails on an array your engine built, even though it is a real array
+expect(context.main.Segments).toBeInstanceOf(Array);
+```
+
+Assert on the shape instead, which holds wherever the value was built:
+
+```typescript
+expect(Array.isArray(context.main.Segments)).toBe(true);
+expect(context.main.Segments).toEqual(['seg_a', 'seg_b']);
+```
+
+The same applies to `instanceof Array` and `instanceof Object` inside your own
+helpers. `Array.isArray`, `typeof`, and `toEqual` are all safe.
+
+### Injecting decisions
+
+`setData(team, patch)` merges a patch into one team's context, by the team's stable index, as a player's surface does: as the team's first participant, through the `ui` surface. So the write is held to that surface's `writes`, and your validators judge it:
+
+```typescript
+await session.setData(0, { pricing: { Price: 10 } });
+await session.tick();
+
+const result = await session.setData(0, { addons: { ExtraShift: true, MarketingPush: true } });
+expect(result).toMatchObject({ ok: false, outcome: { kind: 'validation-rejected' } });
+```
+
+Options choose another writer: `participantId` for a participant other than the first, `ui` for another player surface, and `deletes` for paths to remove after the patch merges. `as: 'system'` writes as the CLI does instead, trusted and ungated (see [what bypasses validation](./validators.md#what-bypasses-validation)), which suits arranging a board the test then plays on:
+
+```typescript
+await session.setData(0, { progress: { Score: 45 } }, { as: 'system' });
+```
+
+`requestTick(team)` asks for the next tick as the team's first participant, so your validators' `RequestTick` gates judge it, where `tick()` is the facilitator's and passes them:
+
+```typescript
+expect(await session.requestTick(0)).toMatchObject({
+    ok: false,
+    outcome: { kind: 'validation-rejected' },
+});
+```
+
+A shared capability is written with `setSharedData`, and every team sees it. With no options it writes as the CLI does; pass `ui: 'session'` to write as the session surface does, held to its `writes`:
+
+```typescript
+await session.setSharedData({ noticeboard: { Message: 'Break at 3' } }, { ui: 'session' });
+expect(session.shared.context.noticeboard.Message).toBe('Break at 3');
+```
+
+`shared` holds the store under `context`, as a session surface's `sessionData.shared` does, so an assertion moves between a test and the surface unchanged. `state().shared` is the store itself.
+
+### Testing game completion
+
+A game with a `maxTicks` limit refuses the tick after it. A game whose tick controller returns `complete: true` reports it on `state().session.complete`, and refuses the next tick:
+
+```typescript
+it('completes when the target is reached', async () => {
+    await session.setData(0, { progress: { Score: 45 } }, { as: 'system' });
+    await session.tick();
+
+    expect(session.state().session.complete).toBe(true);
+    expect(await session.tick()).toMatchObject({
+        ok: false,
+        outcome: { kind: 'tick-failed' },
+    });
+});
+```
+
+### Teams and participants
+
+Pass `teams` for a multi-team game; the default is the game's `teams.min`. In an independent game, `tick()` advances every team and `tick({ team: 1 })` advances one. In a shared-state game every team advances together.
+
+Every team starts with one participant, or the game's `perTeam.minParticipants`. Pass `participants` to choose, as one count or one per team. Zero is allowed:
+
+```typescript
+const session = await createTestSession({
+    packagePath: PACKAGE_PATH,
+    teams: 2,
+    participants: [3, 0], // three on team 1, nobody on team 2
+});
+
+// Your participantJoin hooks ran for the three.
+await session.send({ type: 'addParticipant', teamId: 'team-2' }); // and now for one more
+await session.send({ type: 'moveParticipant', participantId, teamId: 'team-1' });
+```
+
+### Endpoints
+
+Call one with `callEndpoint`. Leave out `uiIdentifier` and the call is system-trusted, as the CLI's is. Name a surface (`uiIdentifier: 'ui'`) to hold the call to that surface's `endpoints` list, as a player's would be. An identifier the package does not declare, the empty string included, is refused rather than trusted: the call answers with a `denied` failure.
+
+```typescript
+const result = await session.send({
+    type: 'callEndpoint',
+    endpointIdentifier: 'openround',
+    request: { round: 4 },
+});
+expect(result).toEqual({ type: 'endpoint', response: { previous: 0, current: 4 } });
+```
+
+A failed call is an answer too, not a throw: `{ type: 'endpointFailure', failure }`, where `failure` is the same `EndpointFailure` a surface's `EndpointError` carries. Assert on its kind and on what had already landed:
+
+```typescript
+const refused = await session.send({
+    type: 'callEndpoint',
+    endpointIdentifier: 'openround',
+    request: { round: 'four' },
+});
+expect(refused).toMatchObject({
+    type: 'endpointFailure',
+    failure: { outcome: { kind: 'invalid-request' }, applied: [] },
+});
+```
+
+### Undo, reset and starting again
+
+```typescript
+await session.send({ type: 'undo' }); // take back the last tick
+await session.send({ type: 'reset' }); // back to tick 0, keeping teams and scenario
+await session.send({ type: 'reinitialise' }); // start again from the package
+```
+
+### Automatic ticks
+
+Timers run on the clock you pass. Pass a `FakeClock` and move it with `advanceClock`, which runs every tick that falls due on the way, so a test says how much time passes rather than waiting for it:
+
+```typescript
+import { FakeClock } from '@seriousgaming/sdk-tools/client';
+
+const session = await createTestSession({ packagePath: PACKAGE_PATH, clock: new FakeClock(0) });
+await session.send({ type: 'advanceClock', byMs: 180_000 }); // three one-minute ticks
+expect(session.state().session.completedTicks).toBe(3);
+```
+
+`pauseTimer`, `resumeTimer` and `extendTick` work as they do from a session UI.
+
+The same clock is what logic reads as `meta.now`, so a `FakeClock` also pins the timestamps a game records: a session started on `new FakeClock(Date.UTC(2026, 0, 1))` hands its first `Init` exactly that instant.
+
+### Pinning a scenario
+
+By default the session resolves the game's default scenario when one is declared, exactly as the dev server does. Your assertions then silently track whatever scenario is currently the default: if someone later marks a different one as default, your expected values change without any test edit. Pin it:
+
+```typescript
+// A specific scenario (it must be listed in the game's `scenarios`)
+await createTestSession({ packagePath: PACKAGE_PATH, scenarioId: 'easy_mode' });
+
+// Or opt out of the default scenario and test the settings defaults
+await createTestSession({ packagePath: PACKAGE_PATH, scenarioId: null });
+```
+
+### The configuration step
+
+A game with a `setup` slot starts at its configuration step. `createTestSession` presses Play for you, so a tick has a game to run. Pass `play: false` to test the step itself, then send `updateSettings` (keyed by settings identifier, for example `{ type: 'updateSettings', payload: { engine: { BaseDemand: 200 } } }`) and `play` as the setup screen would. Settings are fixed from Play onwards, so `state().settings` after `play` is what every tick reads.
+
+## Service callbacks are stubbed
+
+Tests are offline by default, whether they run a whole session or call one logic function. A test session, and the arguments `logicArgs` builds for a unit test (see [Testing the Run function](./testing.md#testing-the-run-function)), answer the service callbacks from the same deterministic stubs, so a test runs without a network or a platform key and gets the same answer every run:
+
+- **`generateText`** answers `[stub <hash>] <excerpt>`: an eight-digit hex hash of the whole request (prompt, system prompt, tier and the rest), then the first 60 characters of the prompt, or of the last `user` message's text, with whitespace collapsed and `...` appended when cut. A request with a `jsonSchema` is answered with the smallest JSON value that satisfies the schema: each property's `const`, first `enum` member or `default` where it has one, `'[stub]'` for a string, the `minimum` or `0` for a number, `false`, and `minItems` entries for an array
+- **`generateSpeech`** stores 100ms of silence as a WAV blob and returns `{ reference: 'blob:<id>', mimeType: 'audio/wav', durationMs: 100, charactersBilled: 0 }`, so `readAsset` resolves it as it would real audio
+- **`extractText`** answers `{ content: '[stub] text of <reference>', mimeType: 'text/plain' }`, without reading the file
+
+With no session behind them, the arguments `logicArgs` builds stub the rest as well: `writeBlob` stores in memory and returns `blob:stub-<n>`, `readAsset` reads back only a blob written in the same test (and rejects anything else, `asset:` references included), and `getPastState` answers `[]`.
+
+| Export                            | From                                                            | Use it to                                                                                       |
+| --------------------------------- | --------------------------------------------------------------- | ----------------------------------------------------------------------------------------------- |
+| `stubGenerateText(request)`       | `@seriousgaming/sdk/testing`, `@seriousgaming/sdk-tools/client` | Compute the stub's answer, so a test can assert on it exactly                                   |
+| `createStubCallbacks()`           | `@seriousgaming/sdk/testing`                                    | Get a fresh set of every stubbed callback, with its own blob store, as `logicArgs` fills them   |
+| `createStubServices(packagePath)` | `@seriousgaming/sdk-tools/client`                               | Get the three service stubs a test session uses, which store speech in the package's blob store |
+
+### Overriding a callback
+
+When a test needs a particular answer, override that callback alone; the others stay stubbed. In a test session, pass `callbacks`:
+
+```typescript
+const session = await createTestSession({
+    packagePath: PACKAGE_PATH,
+    callbacks: {
+        generateText: async () => ({
+            content: [{ type: 'text' as const, text: 'mock response' }],
+            stopReason: 'endTurn' as const,
+        }),
+    },
+});
+```
+
+In a unit test, pass it to `logicArgs` the same way, which makes a spy easy to assert on:
+
+```typescript
+import { logicArgs } from '@seriousgaming/sdk/testing';
+import { expect, it, vi } from 'vitest';
+
+it('includes the LLM report in context', async () => {
+    const generateText = vi.fn().mockResolvedValue({
+        content: [{ type: 'text' as const, text: 'Mocked report.' }],
+        stopReason: 'endTurn' as const,
+    });
+
+    const result = await Run(
+        logicArgs.run({ context, settings: defaultSettings, callbacks: { generateText } })
+    );
+
+    expect(generateText).toHaveBeenCalledOnce();
+    expect(result.capabilities.report.Content).toBe('Mocked report.');
+});
+```
+
+For logic that expects structured JSON output, inspect the options to return the right format:
+
+```typescript
+import type { LLMGenerateOptions } from '@seriousgaming/sdk';
+
+const mockGenerateText = async (options: LLMGenerateOptions | string) => {
+    if (typeof options === 'object' && options.jsonSchema) {
+        return {
+            content: [
+                { type: 'text' as const, text: JSON.stringify({ score: 75, status: 'Good' }) },
+            ],
+            stopReason: 'endTurn' as const,
+        };
+    }
+    return {
+        content: [{ type: 'text' as const, text: 'Tick summary: performance is on track.' }],
+        stopReason: 'endTurn' as const,
+    };
+};
+```
+
+`callbacks` is typed as `Partial<SignatureCallbacks>`, so you only override what your logic uses. In a test session, anything you don't override keeps its default (a stub, or the platform's with `services: 'platform'`), and the override reaches hooks, validators and endpoints as well as the engine. A callback the resource did not declare in `uses` still throws there, override or not.
+
+## Calling the platform
+
+To send the service calls to the Serious Gaming platform, pass `services: 'platform'`:
+
+```typescript
+const session = await createTestSession({ packagePath: PACKAGE_PATH, services: 'platform' });
+```
+
+The session then reads the platform credentials from the same sources as the CLI: the `SERIOUSGAMING_API_KEY` and `SERIOUSGAMING_API_HOST` environment variables, a `.env` file in the package root, and the global settings file. You can also pass them explicitly with `platform: { apiKey, apiHost }`. Keep such tests out of CI unless it has a key.
+
+## Running engine tests
+
+```bash
+# Run all engine tests once
+pnpm test:engine
+
+# Watch mode (re-runs on file changes)
+pnpm exec vitest --config vitest.engine.config.ts
+
+# Run a specific file
+pnpm exec vitest --config vitest.engine.config.ts testing/engine/game.engine.test.ts
+```
+
+Engine tests run in milliseconds per test because there are no subprocesses, no HTTP, and no browser startup.
+
+## CI integration
+
+Engine tests require nothing beyond Node.js: no dev server, no browser, and no platform API key, because the service callbacks are stubbed unless a test asks for the platform. Add them to your CI pipeline alongside unit tests:
+
+```yaml
+# Example GitHub Actions step
+- name: Run tests
+  run: |
+      pnpm test:run      # unit and component tests
+      pnpm test:engine   # engine tests
+```
+
+Run Playwright tests in a separate job or stage, since they need a browser and the dev server.
+
+## API reference
+
+### `createTestSession(options)`
+
+| Option         | Type                          | Description                                                                          |
+| -------------- | ----------------------------- | ------------------------------------------------------------------------------------ |
+| `packagePath`  | `string`                      | Absolute path to the project root (where `seriousgaming.sdk.json` lives)             |
+| `teams`        | `number`                      | Teams to start with. Defaults to the game's `teams.min`                              |
+| `participants` | `number \| number[]`          | Participants per team, one count or one per team. Zero allowed. Defaults to one each |
+| `scenarioId`   | `string \| null`              | Scenario to start on. Omit for the default; `null` for the settings defaults         |
+| `locale`       | `string`                      | Session locale                                                                       |
+| `callbacks`    | `Partial<SignatureCallbacks>` | Replace callbacks your logic receives, such as `generateText`                        |
+| `services`     | `'stub' \| 'platform'`        | Where `generateText`, `generateSpeech` and `extractText` go. Default `'stub'`        |
+| `clock`        | `Clock`                       | The clock timers run on. Pass a `FakeClock` to move time by hand                     |
+| `play`         | `boolean`                     | Press Play on a game with a configuration step. Default `true`                       |
+| `platform`     | `{ apiKey?, apiHost? }`       | Platform credentials, used with `services: 'platform'`                               |
+
+`createTestSession<Context, Shared>(options)` takes two optional type parameters, the engine's generated `Context` and `SharedContext`, and returns a `TestSession<Context, Shared>`.
+
+### `TestSession`
+
+| Member                           | Returns                                             | Description                                                                                                        |
+| -------------------------------- | --------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------ |
+| `send(command)`                  | `Promise<MutationResult>` or `Promise<QueryResult>` | Run a command as the dev server would. A refusal is an answer, not a throw                                         |
+| `state()`                        | `TestSessionState<Context, Shared>`                 | The whole session now, each team's context typed                                                                   |
+| `team(index)`                    | `TestSessionTeam<Context>`                          | One team by stable index: `context`, `participants`, `completedTicks` and the rest. Throws for an unknown one      |
+| `shared`                         | `{ context: Shared }`                               | The shared store now, under `context` as a session surface's `sessionData.shared` holds it                         |
+| `tick(options?)`                 | `Promise<MutationResult>`                           | A facilitator's tick. `{ team }` ticks one team in independent mode                                                |
+| `requestTick(team, options?)`    | `Promise<MutationResult>`                           | A participant's request, which `RequestTick` gates judge. `{ participantId }` to choose who asks                   |
+| `setData(team, patch, options?)` | `Promise<MutationResult>`                           | A participant's write through `ui`, or `{ as: 'system' }` for a trusted one. Also `deletes`, `participantId`, `ui` |
+| `setSharedData(patch, options?)` | `Promise<MutationResult>`                           | A write to the shared store. `{ ui }` holds it to that session surface's `writes`; also `deletes`                  |
+| `settled()`                      | `Promise<void>`                                     | Resolves once everything queued has run, including a timer's tick                                                  |
+| `close()`                        | `Promise<void>`                                     | Stop the session's timers. Call it in `afterEach`                                                                  |
+
+`Command`, `MutationCommand`, `QueryCommand`, `QueryResult`, `MutationResult`, `StateProjection`, `TestSessionState`, `TestSessionTeam`, `ContextPatch`, `SetDataOptions`, `SetSharedDataOptions`, `FakeClock`, `ParticipantCounts`, `TestServices`, `createStubServices` and `stubGenerateText` are exported from the same module.
+
+To call one logic function directly instead, with no session, build its arguments with `logicArgs` from `@seriousgaming/sdk/testing` (see [Testing](./testing.md#testing-the-run-function)).
+
+## Moving from GameRunner
+
+`GameRunner` and `MultiTeamGameRunner` were deprecated in 0.6.0 and have been removed. They drove the engine alone, so a test written with them never saw a hook, a validator, an endpoint, a participant, undo, a per-team tick or a timer. Each call has a `createTestSession` equivalent:
+
+| `GameRunner`                                              | `createTestSession`                                              |
+| --------------------------------------------------------- | ---------------------------------------------------------------- |
+| `GameRunner.create(options)` then `init()`                | `createTestSession(options)`: it is ready at tick 0              |
+| `MultiTeamGameRunner.create({ teamCount })`               | `createTestSession({ teams })`, in either interaction mode       |
+| `runner.tick()`                                           | `session.tick()`, then read `session.team(0)`                    |
+| `runner.update([{ op: 'replace', path: '/a/B', value }])` | `session.setData(0, { a: { B: value } }, { as: 'system' })`      |
+| `runner.update(patches, { teamId: 'team-2' })`            | the same, with team `1`                                          |
+| `runner.updateShared(patches)`                            | `session.setSharedData(payload)`                                 |
+| `runner.getContext()` / `getContext('team-2')`            | `session.team(0).context` / `session.team(1).context`            |
+| `runner.getTick()`                                        | `session.state().session.completedTicks`                         |
+| `runner.complete()`, and `tick()` throwing                | `session.state().session.complete`, and a refused tick           |
+| `runner.init()` to start again                            | `session.send({ type: 'reinitialise' })`, or `undo` for one tick |
+| `persist: true`                                           | Not offered: a test session never touches `.seriousgaming-sdk/`  |
+
+Two behaviours differ, both towards what the dev server does. A tick past the limit comes back as `{ ok: false }` rather than throwing, and a multi-team game runs in its declared interaction mode, where `MultiTeamGameRunner` always ran shared-state.
+
+## Best practices
+
+1. **Leave the services stubbed unless a test is about the model**: the stubs keep tests fast, deterministic, and runnable in CI without an API key. Override `generateText` when a test needs a particular answer
+2. **Start a fresh session in `beforeEach`, and close it in `afterEach`**: each test starts clean, and no timer outlives it
+3. **Assert on computed values, not just the value you set**: the point of an engine test is that the game processes inputs correctly
+4. **Write a decision as a participant when a validator should judge it**: `setData` does by default; `as: 'system'` is the facilitator's and skips validators
+5. **Pin `scenarioId` when the game declares scenarios**: explicit pinning (or `null` for the settings defaults) keeps assertions stable when the default scenario changes
+6. **Run engine tests before Playwright**: if an engine test fails, there is no point running browser tests for the same scenario
+
+## Related
+
+- [Engine testing recipe](../recipes/test-with-engine.md) - step-by-step setup for an existing project
+- [Testing guide](./testing.md) - unit tests for the engine and React components
+- [E2E testing with Playwright](../recipes/e2e-testing.md) - browser-based UI tests
+- [Drive a game from the CLI](../cli-simulation-testing.md) - Test through `sdk tick` and `sdk view` against a live session