Staging

Staging is your app as it really runs: deployed, with its own database and your providers' test accounts. danwo drives the browser against it. It can't emulate anything there, but it still records every run and can break the browser's own calls.

Set it upCopy Anchor Link

Give danwo the staging address instead of a start command. danwo still puts its proxy in front of the browser, so it records the browser's calls:

import { appEnvironment, defineConfig } from "@danwo/sdk"

export default defineConfig({
  testDir: "tests",
  environment: () => appEnvironment({ app: "https://staging.example.com" }),
})

Run it with that config:

npx @danwo/cli test --config danwo.staging.config.ts

Use real test accountsCopy Anchor Link

Nothing is emulated, so your app talks to the real services. Make sure each one is in test mode:

• Payments: Stripe test mode, Paystack and Flutterwave test keys, and their test cards.
• Sign-in: a development Clerk or Auth0 instance, with test users for your tests.
• Email and SMS: a sandbox domain or test numbers, so nothing reaches a real person.

Sign in once and reuse it with saved sessions, with the passwords in secrets, never in the test.

What danwo still addsCopy Anchor Link

• Tests in plain English or with locators, on the real deployment.
• Recordings and video of every run, with the browser's calls and console.
• Faults on the browser's calls. The matrix can make the staging API fail from the browser's point of view. Every fault still hits a real, shared server, so run it with test accounts and narrow it with --faults.

What it can't doCopy Anchor Link

NextCopy Anchor Link