> ## Documentation Index
> Fetch the complete documentation index at: https://docs.vibely.sh/llms.txt
> Use this file to discover all available pages before exploring further.

# Test and verify your app

> What Vibely checks automatically after every change and every publish, and the browser testing you can ask for when a flow needs a click-through.

Vibely checks your app as it builds it. Every turn that changes files is type-checked and, when the change could affect what renders, loaded in a real browser before the agent is allowed to finish. Every web publish is preceded by a real production build and followed by one load of the live URL. On top of that, you can ask the agent to test a specific flow in a browser.

<Frame>
  <img src="https://cdn.vibely.sh/doc/v1/testing-overview.webp" alt="Test and verify your app" width="1200" height="675" />
</Frame>

<Tip>
  **Choose the right check**

  * Something looks broken in the preview: ask the agent to fix it. It reads the errors your preview already captured first.
  * A bug needs clicking through to reproduce, such as sign-in or checkout: ask for a browser test of that flow.
  * A rule should stay true over time: ask the agent to write tests for it.
</Tip>

## What Vibely observes

While verifying, Vibely can see:

* Type errors, broken imports, and packages used without being installed.
* The error overlay, uncaught errors, and render crashes when the app loads.
* Console errors captured from the preview open in your browser.
* Failed requests for your own assets, and Supabase API calls that return errors.
* A page that renders almost nothing, with no error to explain why.

These signals go straight back to the agent, so most problems are fixed before you see them.

## Automatic checks

These run without you asking and don't use extra credits beyond the turn itself.

| Check | When | Blocks the turn? | What it catches |
| - | - | - | - |
| Build health | Every turn that changed files | Yes | Type errors, imports of packages that aren't installed, a broken route tree, a dev server that stopped responding |
| Live app check | Same turn, when the change could render | Yes | What only a page load shows: the error overlay, uncaught errors, hydration mismatches, a blank page |
| Preview console | Same turn | Yes | Errors captured from a real browser showing your preview |
| Production build | Web projects, after the agent finishes | Yes, with up to 2 fix attempts | Problems that exist only in a bundled build |
| Metro bundle check | Mobile projects, after the agent finishes | Yes | The bundle Expo Go will actually load |
| Post-publish check | After a web deployment goes live | No | Problems a first visitor would hit on the live URL |
| Basic security scan | Every publish, in the background | No | See [Security view](/features/security/project-view) |

### The check after every change

When the agent has written or edited files, it can't end the turn until the checks pass.

<Steps>
  <Step title="Build health">
    Route types are regenerated, the TypeScript compiler runs, the code is scanned for imports of packages that aren't in `package.json`, and the dev server is asked whether it's still responding.
  </Step>

  <Step title="Live app check">
    A headless browser in the cloud sandbox opens the routes this turn changed and reports what happened. When several routes need checking, they load in one browser session.
  </Step>

  <Step title="Preview console">
    Errors captured from the preview in your browser since this turn's changes are read back.
  </Step>
</Steps>

A failure isn't a dead end. The error goes back to the agent, which fixes it, and the checks run again, up to 5 attempts per turn.

The live app check is skipped when a turn changed nothing that renders, such as a config file or a script, because the preview and console already cover it.

<Note>
  If the checks can't run at all, for example because the sandbox stopped responding, the turn is accepted and marked **UNVERIFIED** rather than reported as clean.
</Note>

### The production build

A dev server isn't a bundler, so some problems only appear in a real build. Web projects get a full production build after the agent finishes, with up to 2 fix attempts if it fails. Mobile projects get the equivalent: a real Metro bundle.

### After you publish

Some faults exist only in the deployed app. After a web deployment is marked ready, Vibely loads the live URL once and records what a first visitor would have hit. This never blocks the publish: your app stays live, and any findings are recorded as errors you can see and act on. See [Monitoring](/features/grow/monitoring).

## Browser testing

Browser testing checks real user behavior by driving your app's preview in a browser. The agent can open a route, click buttons, fill forms, confirm that specific text actually rendered, read page errors and the network log, and reopen the page at a mobile width.

Use browser testing when:

* a bug needs a click-through to reproduce
* you want a multi-step flow such as onboarding, sign-in, or checkout confirmed end to end
* the issue may depend on routing, authentication, or timing

Browser testing runs only when you ask for it or report a bug. It doesn't run on routine builds, because each run takes time and credits.

**Example**

```text wrap theme={"system"}
Test the checkout flow in the browser and fix anything that breaks.
```

<Tip>
  When something looks broken, the agent first reads the errors your preview already captured. That needs no browser and is usually enough. It opens a browser only when the errors don't explain the problem.
</Tip>

## Tests in your code

Vibely doesn't add a test runner to new projects. If you want automated tests, such as unit tests for a form or a pricing rule, ask for them and the agent writes them and sets up what they need.

```text wrap theme={"system"}
Write tests for the login form's validation rules and run them.
```

Tests you add this way aren't part of Vibely's automatic checks. They run when you or the agent run them.

## Mobile apps

Verification for an Expo project is narrower than on the web, and it matters before you submit to a store.

| What's checked | What that proves |
| - | - |
| Build health passes | Types and routes are consistent, and every import is a declared dependency |
| The Metro bundle builds | The bundle Expo Go loads actually resolves |
| Metro's log is scanned for fatal startup errors | The bundler didn't fail on a bad config |

What isn't checked:

* **Native features in the preview.** The in-editor preview is a web build. It doesn't exercise the camera, push notifications, biometrics, secure storage, or in-app purchases. See [Native features](/features/mobile-apps/native).
* **Real devices.** Nothing taps through your app on a phone before you do. Use Expo Go, TestFlight, or Play internal testing.
* **Store readiness.** A successful native build means the binary compiled, not that it works or will pass review.

See [Ship to stores](/features/mobile-apps/ship).

## FAQ

<AccordionGroup>
  <Accordion title="Do I need to ask for tests on every change?">
    No. Every change is already type-checked and loaded in a browser automatically. Ask for a browser test when you want a specific flow clicked through, and for written tests when you want a rule locked down.
  </Accordion>

  <Accordion title="What if a problem doesn't go away after a few attempts?">
    Ask the agent to test the flow in the browser, so it can see the problem the way a user does. Describe the exact steps and what you expected. If it still isn't resolved, restore a version that worked from [version history](/features/projects/history), then try a smaller change. See [Debugging](/prompting/debugging).
  </Accordion>

  <Accordion title="Does verification run in the background without me knowing?">
    The automatic checks run as part of every turn and every publish. Browser testing never runs silently: it happens only when you ask for it or report a bug.
  </Accordion>
</AccordionGroup>

## Related

<CardGroup cols={2}>
  <Card title="Preview" icon="eye" href="/features/projects/preview">
    Try your app as you build it.
  </Card>

  <Card title="Debugging" icon="bug" href="/prompting/debugging">
    How to describe a bug so it gets fixed.
  </Card>

  <Card title="Security view" icon="shield-check" href="/features/security/project-view">
    Scan your project for vulnerabilities.
  </Card>

  <Card title="Monitoring" icon="chart-line" href="/features/grow/monitoring">
    See errors from your live app.
  </Card>
</CardGroup>


## Related topics

- [Preview and test your app](/features/projects/preview.md)
- [Add payments to your app](/features/grow/payments.md)
- [Optimize your app for SEO and AI search](/features/grow/seo.md)
- [Manage workspace identity and user provisioning](/features/workspace/identity.md)
- [Ship to stores](/features/mobile-apps/ship.md)


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.