Configuration

danwo.config.ts default-exports one object. Every key is optional; defineConfig only types it.

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

export default defineConfig({
  testDir: "tests",
  workers: 2,
  retries: 1,
  model: "anthropic/claude-sonnet-5",
  readiness: { mode: "page+backend", settle: true },
  video: "retain-on-failure",
  environment: () => stripeEnvironment(),
})

This page groups the options. Reference: Config lists each one with its type.

The config loads like a test file: Node removes its types and compiles nothing, so an enum or a namespace won't load. TypeScript in tests lists what works, imports included.

Types aren't checked either, so a misspelt key would do nothing. danwo warns about each key it doesn't know, and suggests the one you likely meant:

danwo: warning: unknown config key `retires` (did you mean `retries`?); danwo ignores it

Finding and running tests复制标题链接

Split slow files across workers复制标题链接

A worker runs one test file at a time, so one long file can keep one worker busy while the others sit idle. splitFiles: true (or danwo test --split-files) hands out single tests instead.

danwo only splits a file whose tests share nothing: no beforeAll or afterAll, and every test on isolation: "test". Other files still run whole. Each test loads its file again, so tests can't pass values to each other through variables at the top of the file.

The order tests run in复制标题链接

danwo promises an order, so a suite whose tests build on each other can rely on it:

• Files start in path order, compared character by character: 10- sorts before 2-, so pad numbers, and capitals sort before lower case.
• A file's tests run in the order they're declared, one after another in one worker. A retry runs straight after the attempt it repeats.
• With workers: 1, each file finishes before the next one starts.

With more workers, files still start in that order but run side by side. Split files hand their tests to different workers, so keep splitFiles off for tests that rely on each other.

Give each worker its own port复制标题链接

Each worker starts its own environment, so two workers can't start the app on one fixed port. freePort() picks a port nothing listens on. It comes from a range the system doesn't hand out to other programs, and no other worker or danwo run gets the same one, so the port is still free when the app starts:

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

export default defineConfig({
  workers: 2,
  async environment() {
    const port = await freePort()

    return appEnvironment({ app: { command: "npm start", url: `http://127.0.0.1:${port}` } })
  },
})

The app gets the port as PORT.

Start an app without the proxy复制标题链接

appEnvironment starts the app behind danwo's proxy, so its calls to providers reach the emulators. Some apps must not be routed at all, such as a tool that runs danwo itself. Pass proxy: false to start the app as it would run on its own:

environment: () =>
  appEnvironment({
    app: { command: "npm start", url: "http://127.0.0.1:4310" },
    proxy: false,
  }),

The app then gets none of the proxy's settings. With no proxy there are no emulators, so adding services as well stops the run with a config error.

What tests run against复制标题链接

Choose the browsers复制标题链接

browser.name picks the engine: Chromium, Firefox or WebKit. A list runs every test once in each, and labels each result with its engine:

browser: {
  name: ["chromium", "webkit"],
  contextOptions: { locale: "en-GB" },
},

danwo test --browser firefox replaces name for one run. Install each engine with npx @danwo/cli install-browser --browser firefox,webkit. Web shows what works in each engine.

Waiting复制标题链接

The agent复制标题链接

Replays复制标题链接

Records and reports复制标题链接

The fault matrix复制标题链接

matrix holds the matrix's own settings:

See Planning and budget for how the budget is spent.

Next复制标题链接