Test Every Pull Request Before It Merges.
When a pull request gets a preview deployment, TestSprite tests that exact URL and comments the result on the PR — pass, fail, and a fix prompt for your coding agent. Turn on a required check and merges wait until it's green.
Works With Any Provider That Posts a Preview Deployment
Waits for the Real Preview
TestSprite triggers off the deployment event, not the build start — so it never tests a URL before it's actually live.
Comments Directly on the PR
Results post as a comment: headline pass/fail count, a quality score, and full detail on every failure.
Block the Merge, Optionally
Toggle "Block PR until tests pass" to make the TestSprite check required — no merging over an open regression.
Draft PRs, Your Choice
Include draft pull requests in the trigger, or wait until a PR is marked ready for review — you decide.
Target URL pattern examples:
https://pr-123.example.com
→ https://pr-{pr}.example.com
https://app-git-login-fix-team.vercel.app
→ https://app-git-{branch-slug}-team.vercel.app
Placeholders: {pr} {branch} {branch-slug} {sha} {short-sha}
Give Reviewers a Real Signal
A green checkmark that never touched the live preview is a guess dressed up as confidence. TestSprite's comment reflects what actually happened when a real browser hit the real URL.
What Lands on the PR
Headline Result
How many tests passed, failed, and were blocked — blocked cases are reported separately since they usually mean a test-environment gap, not a regression.
Failure Detail
Each failure expands to show what was expected, what was observed, and a screenshot from the moment it failed.
Suggested Fix Prompt
A ready-to-copy prompt describing the likely root cause — paste it straight into Cursor, Claude Code, or your coding agent of choice.
Free Community Version
Offers a free community version, making us accessible to everyone.
Trusted By Businesses Worldwide
"Good job! Pretty cool MCP from TestSprite team! AI coding + AI testing helps you build better software easily!"
"TestSprite's automation helps us reduce tons of manual work. The developers can easily catch and resolve bugs earlier in the development process."
FAQ
What has to be true before this works?
Your pull requests need their own preview deployment with a reachable URL — open an existing PR, confirm a deployment is listed, and open that URL to check it loads. If no deployment appears on your PR, TestSprite has nothing to trigger on until your CI/CD pipeline is fixed first.
How do I stop the check from firing before the preview is ready?
Pick the CI/CD event that fires after the deployment is live, not one that fires at build start. TestSprite lists the events it detects on a sample pull request so you can choose the right one and avoid testing a URL that isn't up yet.
Can I require the check to pass before merging?
Yes — toggle "Block PR until tests pass" when you create the trigger, and the TestSprite check becomes required, blocking merges while tests are failing.
Does this add a workflow file to my repository?
No. The trigger is configured entirely inside TestSprite. Nothing is added to your repository, and your existing GitHub Actions workflows aren't touched.
What if my preview URL doesn't follow a predictable pattern?
Configure a stable alias URL for the preview environment if your host generates random subdomains, and point the URL pattern at that instead — it needs to be predictable from the PR number, branch, or commit SHA.
Stop Merging on a Guess.
Connect a repository once. Every pull request gets tested against its real preview deployment, automatically.