Manage Generated Test Files

TestVibe stores test intent and generated automation in your project.

Feature files are the readable source of truth. Generated Playwright files are the executable output.

A tour of the files behind a test: the feature file and the generated spec in Code, how group and feature names become paths, when to regenerate rather than edit, where the files are mirrored in Settings → Repositories, and what to check when files look missing.

Test files and application source

Your test files and the application source serve different purposes:

Corpus	What it is	Where it's managed
Test Files	This project's own features, groups, and generated Playwright specs/configs — everything covered on this page.	Lives in this TestVibe project; optionally mirrored two-way to a Git repo via Settings → Repositories.
Application	The application under test's source, read as context; proposed source changes are reviewed separately. TestVibe reads it to ground Assistant generation and map coverage.	A separate repository connected via Settings → Repositories; browsed in the Application section of the app.

Connecting an application source repository does not automatically mirror test files into it. Configure test-file sync separately and review its target repository and permissions.

Main File Types

File type	Purpose
.feature	Readable Gherkin test intent.
.md	Test instructions authored in Markdown.
.js or .ts Playwright test	Generated browser automation that can be run.
Playwright configuration	Browser, viewport, reporter, and execution settings.
TestVibe settings	Project defaults such as framework, agent, and configuration.

Start with the Gherkin or Markdown instructions and let TestVibe generate the Playwright code.

Where Files Live

Feature files usually live under Features/.

Example structure:

Features/
  Auth/
    Login.feature
    Login.spec.js
  Billing/
    DownloadInvoice.feature
    DownloadInvoice.spec.js
Configurations/
  Default.config.js

Your project may use .ts instead of .js depending on project setup.

How Names Affect Paths

Group and feature names influence project file paths.

TestVibe action	Project effect
Create group Auth	Creates or uses Features/Auth/.
Add feature Login in Auth	Creates Features/Auth/Login.feature.
Rename feature	Updates its name and exported feature path; inspect associated files and external references.
Move feature	Changes its group and exported folder path.
Generate code	Creates or updates the Playwright file associated with the feature.

Use clear names early. Renaming later is supported when available, but it changes project file paths.

Regenerate Or Edit

Situation	Recommended action
The behavior changed	Edit the .feature file and regenerate.
The expected outcome changed	Edit the .feature file and regenerate.
The generated code has a small selector issue	Edit code or improve Gherkin and regenerate.
The code uses the wrong journey	Improve the Gherkin and regenerate.
The test uses a shared helper	Edit generated code if your team owns that pattern.

Regeneration may replace manual code changes. If you manually edit generated code, make sure your team knows which changes should be preserved.

Keep Files Reviewable

• Keep feature names aligned with user behavior.
• Keep generated files near their source feature when possible.
• Review generated code before relying on it for important flows.
• Run one test after generation before running a whole group.
• Update Gherkin when product behavior changes.

If Files Look Missing

Check:

• the selected project
• whether generation completed successfully
• whether the feature is under the expected group
• whether the generated code tab is available for the selected feature
• whether the run completed before saving generated output

See Troubleshoot failed generation if generation did not finish.