> For the complete documentation index, see [llms.txt](https://docs.testvibe.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.testvibe.com/create-tests/manage-generated-test-files.md).

# 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.

## Two Separate Corpora — Test Files vs. App Code

TestVibe keeps two code corpora apart, and this page is only about one of them:

| 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 → Test Files Sync**.      |
| **App Code**   | The application under test's own source — read-only. TestVibe reads it to ground AI generation and map coverage. | A separate repository connected via **Settings → App Repository**; browsed in the **App Code** section of the app. |

Don't confuse the two: connecting an **App Repository** does not put your test files in that repo, and **Test Files Sync** does not give TestVibe write access to your application's source.

## Main File Types

| File type                      | Purpose                                                       |
| ------------------------------ | ------------------------------------------------------------- |
| `.feature`                     | Readable Gherkin test intent.                                 |
| `.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. |

Most users should edit `.feature` files first and let TestVibe generate the Playwright code.

## Where Files Live

Feature files usually live under `Features/`.

Example structure:

```
Features/
  Auth/
    Login.feature
    Login.js
  Billing/
    DownloadInvoice.feature
    DownloadInvoice.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                | Renames the feature file.                                           |
| Move feature                  | Moves the feature file to another group folder.                     |
| 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](/ai-generation/troubleshoot-failed-generation.md) if generation did not finish.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.testvibe.com/create-tests/manage-generated-test-files.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.