Skip to main content
Use this pattern when a browser app signs in through OpenKey and TinyCloud, but an end-to-end test must run unattended. It replaces the human passkey ceremony with a test-only EIP-1193 wallet. The application still uses its production OpenKey external-wallet path, requests a real SIWE signature, and initializes TinyCloud normally. This is a browser-test technique, not an application authentication mode. Do not add a test private key, a bypass flag, or a mock signer to production app code.

What the bootstrap covers

The test account bootstrap has two boundaries:
  1. Before navigation, Playwright installs a test-only wallet provider that can answer account, chain, and personal_sign requests.
  2. After the test selects that wallet in OpenKey, the application performs its usual TinyCloud initialization. With autoCreateSpace: true, that creates the app space when needed. If the app uses encrypted data, its initializer must also create or reuse the owner’s encryption network.
The browser never creates an OpenKey passkey and the test never approves a passkey prompt. It still verifies the integration points that matter: OpenKey widget selection, wallet-backed signing, TinyCloud session setup, and an authorized read or write.

Bootstrap a test account

Install the wallet before page.goto(). The example uses a deterministic Anvil development key so the account is reproducible; it must be used only for test data and must never hold funds, production data, or reusable credentials.
addInitScript() runs before the application’s scripts, so OpenKey’s widget can discover the provider through EIP-6963. Opening shadow roots makes the widget’s wallet picker visible to Playwright; keep that behavior in the test only.

Drive the real application flow

Use your application’s existing OpenKey entry point and select the injected external wallet. The selectors below are from TinyCloud Secret Manager; replace the button selector with your app’s stable test id.
For Secret Manager, its normal initializer calls signIn(), creates its secrets space when absent, then creates or reuses the owner-scoped default encryption network before marking the UI as decrypt-ready. Other applications should keep the same shape: bootstrap the signer in the test, but provision spaces, schemas, networks, and other account resources in the app’s normal initialization path.

Keep runs isolated

  • Use a dedicated test account and test-only resources. A deterministic key is public test infrastructure, not a secret.
  • Use a distinct app or space prefix for E2E data; do not point a test account at user-owned production records.
  • Delete every record the test creates, including after a retry when practical.
  • Run tests serially when they share a deterministic account, or derive a unique resource name from the Playwright worker and test run.
  • Do not live-test provider credentials in this flow. Use a syntactically valid dummy value and disable provider calls, unless the provider integration is explicitly the subject of the test.

When to use a mock instead

Use this account bootstrap when the behavior under test includes OpenKey widget integration, SIWE signing, TinyCloud provisioning, or authorization. Use a module mock for fast component tests and for error states that the real service cannot reliably produce. Keep at least one smoke test on this real path.