Importing & exporting tests

Bring existing Playwright, Cypress, WebdriverIO, Selenium, TestCafe, Postman, HAR or OpenAPI suites in deterministically — no AI credits spent.

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:

Format	What it reads
`playwright`	Playwright spec files
`cypress`	Cypress spec files
`wdio`	WebdriverIO specs
`selenium`	Selenium scripts
`testcafe`	TestCafe tests
`postman`	A Postman collection (bucketed per-folder, or as one test)
`har`	A HAR capture from browser devtools
`openapi`	An OpenAPI / Swagger document

Each converter is 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.

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, an AI fallback can be offered for that fragment. It is opt-in, and it is the only part of an import that costs anything.

After an import

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

Run it. Selectors that were fine in the source tool may need attention.
Check the assertions. A spec whose assertions did not convert is a walkable flow with nothing verifying it — see the assertion note.
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.

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.