# Manage Generated Test Files

URL: https://docs.testvibe.com/create-tests/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:

```text
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) if generation did not finish.