Importing & exporting tests

Vera is not the first tool you have pointed at this app. If you already have Playwright specs, a Cypress suite, a Postman collection or a HAR capture, that work is worth something — importing it gets you a suite with no AI credits spent and no re-recording.

Importing

Eight source formats are supported:

Seven of the eight converters are deterministic: the same input produces the same tests, with no model in the loop. That is why importing is free of AI cost, and why the result is reviewable — you can see exactly which source construct became which step.

selenium is the exception, and it is a whole-format one. Java and Python Selenium have no deterministic converter at all, so those files are imported only when you tick AI conversion in the import dialog. With the box unticked nothing is imported from them and the import says so. AI conversion spends AI credits and needs a working AI setup: an org with no BYOK key and an exhausted onboarding grant is refused rather than falling back to a partial import. Every step it produces is flagged AI-converted — review. Note that JavaScript selenium-webdriver specs are handled by the wdio converter and are deterministic like the rest.

What conversion can and cannot do

Converters translate the parts of a spec that map onto Vera's action vocabulary: navigations, clicks, fills, selections, waits and the assertions that have a direct equivalent.

They cannot translate arbitrary code. A spec with helper functions, loops computing selectors, custom commands or fixtures has logic that is not a step list, and that part will not come across. Every import reports warnings naming what it skipped, along with counts — read them. An import that silently dropped half a spec would be worse than one that refused.

Where a construct cannot be converted deterministically, the same opt-in AI conversion can be offered for that fragment. It is the only part of an import that costs anything — a per-fragment top-up for the seven deterministic formats, and the entire conversion for Java/Python Selenium.

An AI-converted test is a machine-written test, and the workspace treats it as one. If Require review of AI-written tests is on (Settings → Workspace), each test the model had a hand in lands as a draft, queued for review — it does not run, and no suite or schedule picks it up, until somebody approves it. The tests the deterministic converters produced in the same import are unaffected and go straight into service: the flag is per test, so an AI-assisted import of twenty specs that needed the model for one queues that one. Those tests also carry ✦ AI provenance rather than reading as hand-written, which is why they show up in the AI-generated count and in the ROI figures alongside generated tests.

Intent blocks come in through the same validator. No converter produces an intent block yet, so a block reaches an import only from a Vera workspace file. There it is checked like any other step list: a balanced block is restored as written, and one that does not balance is refused for that test with a warning naming it.

After an import

Treat the result as a first draft that is already 90% done:

1. Run it. Selectors that were fine in the source tool may need attention.
2. Check the assertions. A spec whose assertions did not convert is a walkable flow with nothing verifying it — see the assertion note.
3. Factor the repetition. Ten imported specs usually share a login; extract it once as a flow.

Postman and OpenAPI are a different shape

Those two describe APIs, not browser journeys, so they convert into api-request steps rather than clicks. That is genuinely useful — an imported collection gives you backend assertions you can thread into a browser test, which is what makes a chain able to verify what the UI never shows. See Variables.

Exporting

A single test, or a whole project, exports as JSON: the tests with their steps and config, the flows they reference, and the project's variables.

Uses that actually come up:

• Moving a project between Vera instances, or from local to cloud.
• Backing up a suite outside the database.
• Reviewing a change — a diff of two exports shows exactly what changed in a suite, which a UI cannot.
• Bulk editing — export, transform with a script, import back.

Credentials are not what you want in a file you pass around; treat an export as sensitive and check what is in it before sharing.

Exporting a test as code

A single test can also be exported as a runnable spec for Playwright, WebdriverIO, TestCafe or Selenium (Python). The translation is deterministic, with no AI involved. A step with no equivalent in the target becomes a TODO comment at the same spot.

An intent block exports as the steps it recorded, written as ordinary code, with the goal in a comment above them (// Intent: Sign in as the demo user (values: email, password)) and an End of intent comment after. The exported file has no model behind it, so the goal is there for whoever fixes those steps by hand when the page changes.

Flow references survive a round trip

Tests reference flows by id, and ids are per-project — so a naive import would leave every use-flow step pointing at a flow that does not exist in the target project.

Import remaps them: the flows are created in the target project and each use-flow step is rewritten to the new id. A project exported and re-imported somewhere else keeps working.

Limitations

• Run history, artifacts (videos, screenshots) and visual baselines are not included. An export is the suite definition, not its past.
• Schedules, environments and auth configuration are project settings and are not part of a test export.
• Importing into a project adds to it; it does not replace what is there. Two imports of the same file give you two copies.

See also

• Getting started — the zero-AI first green run via import
• Step actions reference — the vocabulary conversions target
• Reusable flows — factoring imported duplication
• The local agent — vera-agent init --import all