Dino Docs

Dino is your personal AI QA harness. Point it at a URL, a Gherkin feature file, an API endpoint or a requirements document and the agent writes scenarios, builds Page Object Models, generates Playwright specs, creates k6 load tests, and heals broken tests, streamed live, on your machine.

This guide covers everything: installing the app, starting the Dino API server, configuring your workspaces and credentials, running every action, browsing what was generated with the workspace tools, executing Playwright dry runs, and watching k6 load tests live.

Core concepts

The 30-second version

1. Start the serverClick ▶ Start Server in the app header. A console window opens, installs what's missing (first time only), and the status dot turns green Connected.
2. Set your workspaceOpen ⚙️ Settings → Project Workspace and point it at your test project folder (absolute path).
3. Add a key & modelSettings → API Key & Model: pick the provider, paste your API key, click ↻ Load Models, select a model, save.
4. Run an actionPick e.g. Generate BDD From URL in the sidebar, fill the URL, click ▶ Run and watch the stream.
5. Check the resultOpen Explore Features / Explore POM to review what was generated, then Dry Run to execute the specs. No terminal needed.

Requirements

Install

From the installer (recommended)

1. Reach out to us via Schedule demo on the AssertRx site, or at support@assertrx.com, to get the installation steps and the installer.
2. Run it. On Windows the installer creates a desktop shortcut and a Start Menu entry (“Dino”) and ships the bundled install/setup-dino-api.bat with the app. The ▶ Start Server button uses it whenever needed. The app does not auto-run after install; launch it yourself.
3. Launch Dino. A splash screen shows briefly, then the main window (1100×780, resizable, min 800×600) appears.

First run

On a fresh install the header shows “Checking…”. The server isn't up yet. Work through these steps once and you're set:

1 · Start the API server

Click ▶ Start Server. On Windows this opens setup-dino-api.bat in its own console window; the server keeps running even if you close Dino (close the console window to stop it). If a server is already listening on the port, the button reports “Server is already running” and simply reconnects.

2 · Point the app at your workspace

Open ⚙️ Settings → Project Workspace and enter the absolute path (e.g. C:/Users/you/projects/my-app). Everything Dino does happens inside this folder. See Project Workspace. If you plan to use the load-testing workflow, set Load Testing Workspace too.

3 · Connect your model

Settings → API Key & Model: choose the provider, paste the API key, click ↻ Load Models to verify the key and list available models, then select one and save. See API Key & Model.

4 · Run your first action

Click any action in the left sidebar (e.g. Generate BDD From URL), fill in the required parameter(s), and hit ▶ Run. Output streams in real time; tool calls (bash / read / write) appear in the panel below the output as they execute. Required parameters have an amber border and a required badge; values are remembered for the next run of the same action.

5 · Check the result

Generated .feature files, POMs and specs are written into your workspace. Browse them with Explore Features / Explore POM, then execute with Dry Run, or generate and run k6 scripts with Run K6.

The Dino API server

Dino talks to a Dino API server over HTTP. The server hosts the agent runtime; the desktop app is the remote control.

Settings · Project Workspace

The workspace is the single most important setting: it's the directory Playwright-oriented actions run in (cwd), where generated files are written, where the managed .env lives, and what the workspace tools (Explore Features / POM, Dry Run) scan.

• Use an absolute path that exists on disk. A missing folder is reported when an action or tool needs it.
• It can be an existing test project, or an empty folder if you plan to run Setup Playwright first.
• Every action request automatically includes the workspace as cwd, so you never configure paths per-action.
• Click Save to persist; the value survives restarts (stored in the app's local settings file).

Settings · Load Testing Workspace

An optional dedicated folder for the k6 load-testing workflow. When set:

• The K6 actions (Setup K6, Generate K6 Tests, Generate K6 Tests from OpenAPI/Swagger) run here instead of the Project Workspace.
• The Run K6 viewer scans and executes scripts here.
• Its .env (if present) is preferred when injecting environment variables into k6 runs, falling back to the Project Workspace's .env.

Leave it empty to run everything in the Project Workspace. K6 actions and the Run K6 viewer simply fall back to it. This keeps load-test scripts and Playwright suites in separate repos or folders when you prefer that.

Settings · API Key & Model

Dino runs on your own provider account. Configure it once and every action uses it.

1. Pick a providerFrom the dropdown. The list comes from your server (/api/providers); if the server can't be reached a fallback set is offered: anthropic, openai, google, deepseek, groq, mistral, openrouter, xai.
2. Paste the API keyFrom your provider console. The field is masked. Changing the provider afterwards clears the model list. Just load models again.
3. Load modelsClick ↻ Load Models: this validates the credentials and lists the models they unlock (shown as provider/model · name).
4. Select the model & saveThe provider, key and model are stored on this device and attached to every run.

Settings · Environment Variables

A built-in dotenv editor. Variables you add here are written to a .env file inside your project workspace, and every action automatically picks that file up. No per-action env configuration needed.

# <workspace>/.env: managed by Dino
ANTHROPIC_API_KEY=sk-ant-...
TEST_BASE_URL=https://staging.example.com

How it works

• Rows are KEY = value pairs. ＋ Add Variable adds a row, ✕ removes one; at least one empty row is always shown.
• Save validates, writes <workspace>/.env and remembers the list in the app settings.
• If the workspace already contains a .env when you first open the panel, its values are imported so you edit what's on disk rather than starting from scratch.
• Actions receive the .env path automatically (the old per-action authEnvDir textbox is gone).
• k6 runs inject these variables into the process environment, preferring the Load Testing Workspace's .env, falling back to the Project Workspace's.

Rules

• Names: letters, digits and underscores; must start with a letter or underscore ([A-Za-z_][A-Za-z0-9_]*).
• Duplicate names are rejected; blank rows are dropped on save.
• Values may contain newlines; they're escaped transparently on write.
• Surrounding quotes are stripped when an existing file is imported; # comment lines are ignored on import.

Settings · Test Agents

Choose the tester perspectives the Generate BDD From URL action should consider while writing scenarios. Leave everything unchecked for default coverage.

The selection is passed to the agent automatically as tester roles; only Generate BDD From URL uses it (the old per-action testerRoles field is injected for you).

Actions

The sidebar lists every prompt your Dino server exposes: built-ins plus any custom workflows you've added on the server. Kebab-case names are shown as friendly titles (generate-pom-from-url-cli → “Generate POM From URL CLI”). Selecting one shows its parameter form; fill it in and click ▶ Run.

Built-in actions

Parameters

Each action declares its own form. Fields are labelled required or optional (required inputs get an amber border), and the values you typed last time are restored automatically per action. Common parameters:

Any parameter whose name ends in File gets a native file picker; any ending in Dir gets a folder picker, including parameters of custom actions you add on the server.

The pipelines

Actions compose. Typical end-to-end flows in one workspace:

── Playwright functional flow ──────────────────────────────
setup-playwright          →  scaffold the project (once)
generate-bdd-from-url     →  feature files for your app
generate-pom-from-url-cli →  page objects for the same screens
generate-spec-from-feature →  runnable specs wired to the POMs
Dry Run                   →  execute + HTML report (no AI)
heal-playwright-failures  →  when selectors drift, self-heal and re-verify

── k6 load-testing flow ────────────────────────────────────
setup-k6                        →  scaffold the load-test project
generate-k6-test-from-endpoint  →  scripts for chosen endpoints
generate-k6-test-from-openapi   →  scripts for a whole API spec
Run K6                          →  execute + live progress (no AI)

Run, Stop & Output

While an action runs, two panels tell you exactly what the agent is doing:

• Output. The streamed transcript: agent narration, tool invocations with trimmed tool output, and a final ✅ Session complete marker.
• Tool Calls: every tool invocation as it happens (bash, read, write, …), with ▶ flipping to ✓ (or ✗ on failure), so nothing happens hidden.

When the run finishes, a usage line summarizes the session (tokens (in / out / cache read / write), cost, and tool-call count), and the footer keeps the latest token count and cost visible at all times.

Explore Features

📁 A read-only browser for every Gherkin .feature file in your project workspace. The list on the left is sorted by path; the first file is auto-selected.

• Renders Gherkin nicely: feature title, collapsible scenarios, colour-coded Given/When/Then keywords, tags, example tables and doc strings.
• Click a file's name (or ⧉ Copy Path in the reader header) to copy its path, then paste it straight into an action parameter like Generate Spec From Feature.
• Reader controls (shared with Explore POM): A−/A+ font size (12–28 px, persisted), ⟲ reset, ⛶ maximize the reader (Esc restores), ☰ hide/show the file list.
• Great for reviewing what Generate BDD From URL just wrote, before committing anything.

Explore POM

🧩 The same viewer for generated Page Object Models, rendered as friendly syntax-highlighted code (keywords, strings, Playwright locator APIs, comments). A file is listed when it matches the POM naming convention or lives in a POM directory:

tests/pom/login.pom.ts     ✓  *.pom.ts|js|mjs|cjs|java
tests/pom/helper.ts         ✓  any code file inside a *pom* directory
src/pages/home.pom.js       ✓
src/util.ts                 ✗  no pom in name or path

The same skip-list, sorting, copy-path and reader controls as Explore Features apply.

Dry Run

🎬 Execute Playwright tests in your workspace without leaving the app. A plain local run, no AI involved. Dino runs npx playwright test in the project workspace and streams the results live.

Controls

Details

• Only Dino-style *.spec.ts files are listed in the spec picker.
• The exact command is echoed at the top of the result screen, e.g. $ npx playwright test tests/login.spec.ts --project=chromium --reporter=list,html.
• Runs stream per-test results with the list reporter and write the HTML report (it never auto-opens; use the report button).
• Runs execute with CI=1, so interactive prompts are suppressed (note: this also honours any retries configured in your Playwright config).
• Lines are colour-coded live (passed / failed / skipped / flaky), and the summary parses Playwright's counts, including flaky (failed first attempt, passed on retry), skipped, interrupted and did not run, not just the exit code.
• Only one dry run at a time: the buttons disable while a run is in progress.

Run K6

⚡ Execute k6 load tests and watch progress live. Again a plain local run, no AI involved. Dino runs k6 run <script> in the k6 workspace (Load Testing Workspace when set, else Project Workspace).

Which scripts are listed

The viewer scans the workspace for .js / .mjs / .cjs / .ts files whose contents import from the k6 module (i.e. anything containing import … from 'k6/…' or 'k6'). The same noise directories as the other explorers are skipped. The hint under the toolbar shows which workspace the scripts will run in.

Controls

Details

• Variables from your managed .env (Settings → Environment Variables) are injected into the run's environment, so scripts can read them via __ENV.
• k6's progress bar is redrawn in place (no endless scrolling), and colour output is normalized.
• The summary parses k6's end-of-test report. Failed checks and failed thresholds are counted and shown.
• Exit codes are translated for you: 99 = thresholds failed, 100 = script exception, 101 = script could not be loaded, 102 = aborted.
• Only one k6 run at a time; buttons disable while it's in progress.

Troubleshooting

Security & Privacy

• Your keys stay yours. Provider API keys are stored in the app's local settings file on your device and forwarded with each request. They're never written to the Dino server's disk.
• The workspace is yours. The agent operates through real tools inside the folder you choose; every invocation is visible in the Tool Calls panel. Nothing runs hidden.
• Secrets live in .env. Managed environment variables are written to your workspace's .env, the standard Playwright/CI location, so your existing .gitignore rules apply.
• Hardened shell-outs. Dry-run browser projects and k6 script paths are validated against strict whitelists before being executed through a shell; report paths are resolved by the main process, never trusted from the page.
• Sandboxed renderer. The UI runs with context isolation and no Node integration; the renderer can only reach the main process through a narrow, validated IPC API.

Found something sensitive? See the repository's SECURITY.md for how to report it responsibly.

FAQ