How to Test Vercel Preview Deployments Automatically in 2026

The short answer

You do not add a workflow file, and you do not write a script that scrapes the preview URL out of your build logs. TestSprite installs as a GitHub App, listens for the deployment event your pipeline already produces, works out the preview URL from a pattern you define once, runs your tests against it, and posts the result back as a comment on the pull request.

Setup takes about ten minutes, needs admin rights to install a GitHub App, and requires no changes to your repository.

Prerequisite: confirm the pull request produces a deployment

TestSprite triggers off a deployment event, so that event has to exist before anything else will work. Open any existing pull request and confirm a deployment is listed with a clickable URL, then open that URL and check the preview environment actually loads.

On Vercel this appears as a bot comment on the pull request listing the project, a Ready status, and a link to the preview. AWS Amplify, Netlify, and self-hosted pipelines that create GitHub deployments all produce the same signal in their own format — what matters is that a deployment exists and its URL is reachable.

Step 1 — connect GitHub to your workspace

This is a one-time setup per workspace. In TestSprite, go to Workspace Settings → Integrations, find the GitHub row, and click Connect. You will be redirected to GitHub to choose the organisation or personal account that owns the repository, then pick All repositories or Only select repositories and click Install & Authorize.

The permissions requested are worth knowing before you approve them:

Write access is used to post test results back to your pull requests and commits. TestSprite does not push commits or modify your workflow files. If your organisation is not listed during installation, you do not have permission to install GitHub Apps for it — an organisation owner needs to approve it.

Step 2 — connect the repository to a project

Open the TestSprite project you want to connect, go to the GitHub Action tab, and click Connect GitHub Action. Then choose how tests should be triggered:

One trigger is enough to start. You can create both — they run independently of each other.

Step 3 — pick the event that means "deployment finished"

Select the Pull Request tab, paste the URL of an existing pull request that has a working preview deployment, and click Detect Events. TestSprite lists the CI/CD events it found on that pull request — GitHub Actions checks, bot comments from Vercel or Amplify, workflow runs — and you choose which one starts a run.

Pick the event that fires after the deployment is live and the URL is reachable. This is the single most common way to get the setup wrong: an event that fires at build start will run your tests against a URL that is not up yet, and every test will fail.

Step 4 — fill in the target URL pattern

Every hosting provider names preview URLs differently, so you tell TestSprite how to construct the URL for any given pull request. Five placeholders are available:

Match the pattern against a real preview URL, character by character:

Vercel's default preview hostnames are built from the branch, which is why {branch-slug} is usually the right placeholder there rather than {pr}. If your host generates random subdomains with nothing predictable in them, configure a stable alias URL for the preview environment and use that instead.

A push trigger needs no pattern at all — it runs against the configured URL of whichever TestSprite environment you select, so pick Dev for dev or Production for main.

Step 5 — send a test event before you save

Click Send Test Event. This runs your tests against the sample pull request exactly like a real trigger would, so you can preview the whole flow before committing to it. Wait roughly 30 seconds, then return to the pull request on GitHub — a TestSprite comment appears.

Open the URL in that comment before going any further. Confirm it is reachable and points at the environment you expect. If it is wrong, correct the pattern and send another test event rather than waiting for the next pull request to find out. Once the run completes, TestSprite updates the same comment with the result.

When the test event looks right, click Create Trigger. It appears in the Triggers list marked Active and runs automatically on every future pull request. Two optional toggles are worth setting deliberately:

If your preview sits behind Deployment Protection

This is the failure mode that looks like a passing setup. With Vercel's Deployment Protection enabled, every preview URL sits behind an authentication wall, and an external tester receives the login page instead of your application. The tests do not error — they describe a page nobody expected.

The check in Step 5 catches it: open the URL from the TestSprite comment in a private window. If you see a Vercel login screen, protection is on. The two ways forward are to disable protection for the preview environment, or to use Vercel's Protection Bypass for Automation, which generates a secret that Vercel accepts as an x-vercel-protection-bypass query parameter as well as a header. Because the target URL pattern is just a URL, the query-parameter form can be appended to it:

https://app-git-{branch-slug}-team.vercel.app?x-vercel-protection-bypass=YOUR_SECRET

Generate the secret under Project Settings → Deployment Protection → Protection Bypass for Automation. Be deliberate about this one — it stores a bypass secret in a settings field, so disabling protection on preview environments is the cleaner option when your previews contain nothing sensitive.

Reading the result

When a run completes, TestSprite updates its pull request comment — or commit check — with the outcome. The comment is structured, and the last row is the one that matters most if an AI agent wrote the code:

Every result links back to the full report in TestSprite.

Verify your setup

Before you rely on the integration, confirm all five:

1. The GitHub integration shows as Connected in your workspace

2. The repository appears inside the project's GitHub Action tab

3. A trigger is listed and enabled

4. A test event produced a TestSprite comment (pull request) or check (push)

5. The URL in that comment or check opens the correct deployed environment

Troubleshooting

The command-line alternative

The GitHub App is the right answer when your pipeline already produces deployments. If you would rather drive the run from your own workflow — or you are not on GitHub at all — the open-source TestSprite CLI does the same job from any CI system. It is free to install and Apache-2.0 licensed:

npm install -g @testsprite/testsprite-cli
testsprite setup

Point a project at a URL you have already resolved, and run the suite to a verdict:

testsprite project update prj_abc123 --url "$PREVIEW_URL"
testsprite test run --all --project prj_abc123 --wait --output json
#   exit 0 = everything passed, exit 1 = something is broken

testsprite ci init github scaffolds a workflow for this path, and the CLI needs only TESTSPRITE_API_KEY in the environment, so it drops into CircleCI, GitLab, Jenkins, or Azure Pipelines just as easily. Use --report junit --report-file <path> for a sidecar those systems ingest natively.

If the flows you care about live behind your application's own login, store a test account on the project so runs can authenticate. Both flags are required together:

testsprite project update prj_abc123 \
  --username qa@example.com \
  --password-file ./.secrets/qa-password

Frequently asked questions