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

# PR Testing: Automatic Tests on Every Pull Request

> Learn how Opslane watches your GitHub repos and automatically triggers a full browser test run every time you open or update a pull request.

Every pull request you open is a potential regression. Opslane eliminates the manual work of writing and running tests by automatically launching a full browser test run the moment a PR is created or updated. You get pass/fail feedback directly in the PR — no CI configuration, no test scripts, no waiting.

## How the trigger works

Opslane installs as a GitHub App on your repository. When you grant access, the app subscribes to pull request events from GitHub's webhook system. Any time a PR is opened, synchronized (new commits pushed), or reopened, Opslane receives the event and kicks off a new test run immediately.

<Steps>
  <Step title="PR is opened or updated">
    A developer pushes commits and opens a pull request, or pushes new commits to an existing PR. GitHub fires a webhook event to Opslane.
  </Step>

  <Step title="Opslane detects the preview URL">
    Opslane reads the PR's deployment status to find the live preview URL for the branch — the same URL a reviewer would open in their browser.
  </Step>

  <Step title="A browser run is launched">
    Opslane spins up an ephemeral Chromium browser, navigates to the preview URL, and begins crawling and testing the app. See [Browser runs](/concepts/browser-runs) for details on what happens inside the run.
  </Step>

  <Step title="Results are posted to the PR">
    When the run finishes, Opslane posts a comment on the PR with a pass/fail verdict, screenshots, and a video recording. The GitHub status check is updated accordingly.
  </Step>
</Steps>

<Note>
  Opslane requires a live preview deployment for the PR branch — for example, a Vercel preview, a Netlify deploy preview, or any URL that becomes available when the branch is deployed. Opslane does not build or deploy your app itself.
</Note>

## What gets tested

Opslane does not rely on test scripts that you write. Instead, it crawls the deployed preview of your PR branch, discovers pages and interactive flows, and verifies that they behave correctly. The test scope is determined automatically based on what Opslane finds in the running app.

This means:

* You never write or maintain test files.
* Coverage grows as your app grows — new pages and flows are discovered on subsequent runs.
* Opslane checks the same app that your users will interact with, not a mocked or headless version.

<Tip>
  If your app requires authentication, you can configure login credentials so Opslane can reach protected pages. Refer to the setup guide for details.
</Tip>

## How regressions are detected

Opslane compares the behavior of the PR branch against the baseline established from your main branch. A regression is flagged when the PR branch exhibits a failure that wasn't present on the baseline — for example, a page that previously loaded now returns an error, a button that was clickable is now broken, or a form that submitted successfully now fails.

<Tabs>
  <Tab title="When a regression is found">
    * The GitHub status check on the PR is set to **failed**.
    * The PR is blocked from merging (if branch protection rules require the Opslane check to pass).
    * Opslane posts a comment identifying which flows failed, with screenshots and a video of the failure.
  </Tab>

  <Tab title="When no regression is found">
    * The GitHub status check is set to **passed**.
    * The PR is unblocked for merge.
    * Opslane still posts a comment summarizing which flows were tested and confirmed working.
  </Tab>
</Tabs>

<Warning>
  Merge blocking requires that you configure Opslane's status check as a required check in your repository's branch protection rules. Without this, Opslane will still report results but cannot block merges automatically.
</Warning>

## The difference from writing your own tests

Most test frameworks require you to write scripts that describe exactly what to click, what to fill, and what to assert. This takes time to author and becomes a maintenance burden as your UI changes.

<CardGroup cols={2}>
  <Card title="Traditional test scripts" icon="file-code">
    You define every step manually. Tests break when the UI changes, even if the app is working correctly. Keeping tests up to date requires ongoing engineering effort.
  </Card>

  <Card title="Opslane PR testing" icon="sparkles">
    Opslane determines what to test by exploring your live app. No scripts to write or maintain. The run adapts as your app evolves.
  </Card>
</CardGroup>

This approach is complementary to unit tests and integration tests you already have. Opslane focuses on what actually runs in the browser — the end-to-end behavior that users experience.