Writing tests
Saved sessions
Sign in once per worker, and start every test that needs it already signed in.
Most tests start with a signed-in user. Signing in on every test is slow, and it isn't what those tests are about. A saved session signs in once per worker, keeps the result, and starts each test that names it already signed in.
Define a session
Add it to danwo.config.ts. setup signs in, and check (optional) confirms a kept sign-in still
works:
import { defineConfig } from "@danwo/sdk"
export default defineConfig({
testDir: "tests",
secrets: { password: { value: process.env.APP_PASSWORD ?? "", purpose: "password" } },
sessions: {
ada: {
async setup({ app, screen, secret }) {
await app.open("/login")
await screen.getByLabel("Email").fill("ada@shop.test")
await screen.getByLabel("Password").fill(secret("password"))
await screen.getByRole("button", { name: "Sign in" }).click()
},
async check({ app, screen, expect }) {
await app.open("/account")
await expect(screen.getByRole("heading", { name: "Account" })).toBeVisible()
},
},
},
})The setup gets the same fixtures a test does, mail and agent included, so an emailed code or an
agent step works in it too.
A setup can also seed rows for its user. See Your app's data in tests.
Use it
import { test } from "@danwo/sdk"
test.use({ session: "ada" })
test("shows the order history", async ({ app, screen, expect }) => {
await app.open("/account/orders")
await expect(screen.getByRole("heading", { name: "Your orders" })).toBeVisible()
})Opt a test out with { session: false }. A file can also define a session of its own, with
test.session(name, setup).
What's kept
| Part | Kept how |
|---|---|
| Browser state | cookies, localStorage and IndexedDB, loaded into each test's fresh browser |
| The backend's side | the user and session in the emulators and your database, in a snapshot slot of its own |
| Flight records | never hold the browser state |
Each session has its own snapshot slot, so a test that uses no session still starts signed out, even right after one that used Ada.
When it runs again
- The first test that names the session runs its setup.
- When
checkthrows, the session is set up again. - A full reset drops every kept session.
- In
danwo matrix,--include-setupsigns in afresh for every trial, so faults reach the sign-in too.
When setup fails
A setup that throws fails every test that uses the session, with SESSION_SETUP_FAILED and the
setup's own error. It's reported once, pointing at the setup's line, and not run again for each
test.