Pull request
The result, on the pull request.
TestSprite comments as soon as the run starts, then updates that comment with the result: what failed, at which step, and why. Push the fix and the new commit is tested again.
Nothing mergesunverified.
Every pull request is tested against its own preview before it lands, the moment your CI says the preview is up. The result posts to the PR, where the review already is.
Wired to the CIyou already have.
Starts on your CI's signal
Paste a recent pull request and TestSprite lists what your CI did on it: deployments, workflows, checks, statuses, bot comments. Pick the one that means the preview is up.
Tests each PR's own preview
Each pull request runs against its own preview URL, built from a pattern you set once. A push to a branch tests the environment you choose instead.
Blocks the merge on failure
Turn on the merge gate and a failing run fails the TestSprite status check. Make that check required, and the pull request waits until it passes.
History
Every run lands in one history.
Runs from pull requests sit beside scheduled, manual and CLI runs, against the same suite and kept the same way. When a check goes red, the run behind it is one click away.
Setup
Installed once, for the whole workspace.
Install the GitHub App once and choose exactly which repositories it can reach. Then each project adds a trigger of its own, and its next pull request is tested.
Two ways in
The GitHub App, or the CLI in your pipeline.
TestSprite never builds or deploys your app. It tests the deployment your CI already makes, from whichever side fits your setup.
GitHub App
For preview deployments
Best when a platform like Vercel or Netlify deploys every pull request. Install the App, add a trigger, and results come back to the PR as a comment and a status check. No workflow file to write.
GitHub integration docsCLI
For full control of the pipeline
Run the TestSprite CLI as a step in GitHub Actions or any CI that can run a shell command. A run that does not pass fails the step; on GitHub Actions the failures show on the pull request, and JUnit XML reports plug into GitLab or Jenkins.
CI/CD guideGood to know
Frequently askedquestions
A repository on GitHub, and a deployment TestSprite's cloud can reach: a preview of each pull request, or an environment a branch deploys to. TestSprite never builds or deploys your app. It tests the deployment your CI already makes.