TestInspector provides three export formats for test suites created through its AI chat interface: Playwright TypeScript for teams running browser automation in JavaScript/TypeScript CI environments, Selenium IDE (.side) for teams using the Selenium ecosystem or migrating existing test libraries, and Gherkin for teams working in a behavior-driven development workflow where test specifications are written in plain English and shared with non-technical stakeholders. Each export produces a file that can be used independently of TestInspector — the output is standard format code that any QA engineer or test framework can consume without requiring the TestInspector platform to execute it.

Exports are generated from test suites that were created using TestInspector's AI step generator or browser extension recording. The platform converts the internal step representation — structured test steps, assertions, and variable references — into the syntax conventions of each target format. This guide covers what each export format produces, how to use the exported files in a CI/CD pipeline or Selenium IDE, and which format is most appropriate for common team configurations. For teams evaluating TestInspector as a test authoring platform, the export functionality is relevant to interoperability requirements — the ability to move tests out of the platform if your tooling choices change.

What the TestInspector Export System Produces and How It Works

TestInspector's internal test representation stores each test as a sequence of structured steps: navigate, click, fill, assert, HTTP request, accessibility check, or wait. Each step has a target selector, an action, and optional assertions. Variable references use the {{VARNAME}} syntax throughout. When you export a test or suite, the platform converts this step representation into the target format's equivalent constructs.

The conversion happens at the step level. A fill input step in TestInspector maps to a locator.fill() call in Playwright, a store command in Selenium IDE, and a step description in Gherkin. An assertion on response status code maps to expect(response.status()).toBe(200) in Playwright, a verification command in Selenium IDE, and a Then clause in Gherkin. Variable references are preserved in each format using that format's variable syntax conventions.

The export is a point-in-time snapshot of the test suite. Changes made to the test in TestInspector after export are not reflected in the exported file — you need to re-export to get an updated version. For teams using the exported format as their primary test artifact, this means the export workflow should be part of the CI/CD process: export on each test run rather than maintaining a manually checked-in copy.

Export is available at the suite level — all tests in a suite are included in a single export operation. Individual test export is also supported. For teams building test automation infrastructure, the export capability means TestInspector can serve as the authoring layer while the execution layer remains in Playwright or Selenium — a useful separation if existing CI/CD infrastructure already runs those frameworks.

Exporting TestInspector Tests to Playwright TypeScript

The Playwright TypeScript export produces a .ts file structured as a standard Playwright test file using the @playwright/test library. Each test in the suite becomes a test() block, with steps mapped to Playwright API calls using page, locator, and request. The file includes the necessary imports at the top and can be placed directly into a Playwright project's test directory and executed with npx playwright test.

Selector handling in the Playwright export reflects TestInspector's selector model. TestInspector uses CSS selectors and ARIA role-based selectors for element targeting. In the export, these map to page.locator('css-selector') or page.getByRole() calls depending on how the selector was originally defined. The self-healing selector mechanism in TestInspector — where the AI suggests alternative selectors when an element is not found — is not reproduced in the export, since the exported file is static Playwright code. The exported selectors represent the primary selectors used at the time of export.

Variable references are handled in one of two ways in the Playwright export, depending on the variable type. Environment variables (credentials, base URLs) are mapped to process.env.VARNAME references, which means the test expects those environment variables to be set in the execution environment. Dynamic variables like {{TIMESTAMP}}, {{ALPHANUMERIC}}, and {{TOTP:secret}} are replaced with equivalent JavaScript implementations using Date.now(), random string generators, and TOTP libraries respectively.

To use the Playwright export in a CI/CD pipeline:

• Export the suite from TestInspector and save the .ts file to your test directory
• Ensure @playwright/test is installed: npm install --save-dev @playwright/test
• Set environment variables for any variables that were marked as sensitive in TestInspector
• Run tests: npx playwright test path/to/exported-file.spec.ts

The Playwright export is the right format choice for teams where the primary CI/CD test runner is already Playwright, or teams that want to maintain the exported tests as part of their source code repository with version control. For these teams, TestInspector functions as the test authoring and editing interface, and Playwright is the execution engine. See Astaqc's software testing services for guidance on architecting this kind of split authoring-execution setup.

Exporting to Selenium IDE (.side) Format

The Selenium IDE export produces a .side file, which is the native project format for Selenium IDE. A .side file is a JSON document containing the test suite structure: suites, tests, and commands. When opened in Selenium IDE (available as a browser extension for Chrome and Firefox), the file loads the tests for editing, replay, and export to Selenium WebDriver code in Java, Python, JavaScript, or C#.

The .side format is most relevant in two situations. First, teams that have an existing Selenium IDE test library and want to consolidate new tests created in TestInspector with their existing collection can import the .side export into Selenium IDE alongside existing files. Second, teams that use Selenium Grid for distributed test execution can use the .side file as the source for selenium-side-runner execution: selenium-side-runner path/to/file.side runs the tests against a target browser via command line, without opening Selenium IDE.

A key limitation of the Selenium IDE format is that HTTP request steps are not representable in Selenium IDE's command model. Selenium IDE is a browser automation tool, not an API testing tool. TestInspector tests that include HTTP request steps (GET, POST, PUT, PATCH, DELETE with assertion) will have those steps omitted or represented as comments in the .side export, with a note indicating that manual implementation is required. Tests that are exclusively browser-based will export completely without modification.

For teams working primarily in the Selenium ecosystem and using Selenium Grid for parallel execution, the .side export is the most direct path to integrating TestInspector-authored tests into existing Selenium infrastructure. For teams transitioning from manual to automated testing, Selenium IDE's visual playback is also useful for demonstrating test coverage to non-technical stakeholders before moving to code-level execution.

Exporting to Gherkin Format and BDD Workflows

The Gherkin export produces a .feature file in standard Gherkin syntax: Feature, Scenario, and steps using the Given / When / Then keywords. Each TestInspector test becomes a Scenario, and each step is converted to a Gherkin step description that describes the action in plain English. The resulting .feature file is readable by non-technical stakeholders and compatible with BDD frameworks including Cucumber (Java, JavaScript, Ruby), SpecFlow (.NET), and Behave (Python).

The Gherkin export does not include step definition code. A .feature file describes the test in human-readable terms, but execution requires step definitions — functions that map each Gherkin step pattern to actual browser automation code. When you export from TestInspector to Gherkin, you receive the feature file with step descriptions, but the step definitions must be written separately. For teams already using Cucumber or SpecFlow with an existing step definition library, the exported feature file can often be mapped to existing step definitions with minimal adjustment.

The Gherkin export is most useful in two contexts. First, for teams where product managers, business analysts, or compliance teams need to review test scenarios in plain language: the .feature file is readable without technical knowledge and can be included in documentation, reviewed in pull requests by non-engineers, or used as acceptance criteria for features. Second, for teams that maintain separate specifications and test implementations and want TestInspector to generate the specification layer while the engineering team maintains the implementation layer.

Variable handling in the Gherkin export uses Gherkin's parameter syntax. Variables that are referenced in test steps appear as quoted parameters in step descriptions, following Cucumber expression conventions. Dynamic variables like TIMESTAMP and ALPHANUMERIC are represented as Gherkin Examples table rows in Scenario Outline format where applicable.

For teams working within a BDD workflow and looking to accelerate test case creation, the manual vs. automated testing guide covers where BDD fits in a mixed testing strategy, and Astaqc's testing documentation service can help structure Gherkin scenario libraries that serve both execution and documentation purposes. Additionally, the complete software testing guide covers how BDD scenarios relate to other test types in a complete testing strategy.

Frequently Asked Questions

Which export format should a team use if they already have a Playwright test suite?

Use the Playwright TypeScript export. It produces files that are structurally compatible with a standard Playwright project and can be added to an existing test directory. The exported tests run with the same npx playwright test command as hand-written tests. Teams that want to treat TestInspector as the authoring interface and Playwright as the execution engine will find this format the most direct integration path.

Does the exported Playwright file include self-healing logic from TestInspector?

No. The self-healing mechanism in TestInspector — AI-suggested alternative selectors when an element is not found at run time — operates within the TestInspector runner. The Playwright export is static code that uses the primary selectors defined in each test step. If a selector breaks after export, the Playwright test will fail with a standard Playwright element not found error, without the AI retry behavior. Teams that rely on self-healing should continue running tests through TestInspector rather than via the export.

Can exported Selenium IDE files run on Selenium Grid for parallel execution?

Yes. The .side file can be executed via the selenium-side-runner command-line tool, which supports specifying a remote Selenium Grid endpoint with the --server flag. Parallel execution across multiple browsers and browser versions is possible through Grid configuration. The limitation is that HTTP request steps and accessibility assertions from TestInspector will not be included in the .side export, since the Selenium IDE format does not have native support for those step types.

Does the Gherkin export include step definitions, or only the feature file?

The Gherkin export includes only the .feature file with Scenario blocks and step descriptions. Step definitions must be written separately by the development team using the BDD framework of their choice. For teams with an existing Cucumber or SpecFlow step library, the exported feature file can often reuse existing step definitions with minor adjustments. For teams building a BDD setup from scratch, step definitions are a separate implementation effort.

How are TOTP variables handled in the Playwright export?

TOTP variables ({{TOTP:secret}}) are converted to a TOTP generation call in the Playwright export using the otplib or equivalent TOTP library. The export includes a comment indicating where the TOTP secret should be injected — typically from an environment variable. The actual TOTP secret value is not embedded in the exported file for security reasons. Teams using TOTP in exported tests need to add the TOTP library as a dependency and configure the secret via their CI/CD secret management system before running the exported file.

Can TestInspector export a subset of tests from a suite rather than the entire suite?

Yes, TestInspector supports exporting individual tests in addition to entire suites. When exporting an individual test, the output is a self-contained file in the chosen format containing only that test's steps. Suite-level exports include all tests in the suite in a single file. For teams that want to export specific tests for inclusion in an existing test file, individual test export provides that granularity. See TestInspector for the full list of export and integration options available.