What the bootstrap covers
The test account bootstrap has two boundaries:- Before navigation, Playwright installs a test-only wallet provider that can
answer account, chain, and
personal_signrequests. - 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.
Bootstrap a test account
Install the wallet beforepage.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.
exposeFunction() installs the signer before navigation and avoids depending
on the order of multiple browser init scripts. addInitScript() then installs
the provider before the application’s scripts, so OpenKey’s widget can discover
it 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.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.
