Pull request testing · GitHub & GitLab

Merge the PR.
Not the Bug.

Pie opens your preview, uses the change like a customer would, and answers on the pull request: what works, what broke, and a replay of every step.

Sample pull request. Row labels and their order are Pie’s own.

Fi
Tilt
Red Points
Dick's Sporting Goods
Lumo
Prado
Focal
Fairway
Teams shipping with Pie
More customers →

The difference

All Green. Still Broken. Pie Uses the Change Before You Merge.

CI ran the tests written before this change. Review and AI review read the diff. Nobody used the change, so the broken checkout went out with a wall of green.

Every other check on the pull request

  • CI214 Tests Passedthe ones written before this change
  • Code ReviewApproved“Looks right.”
  • AI ReviewLooks Good2 suggestions on naming
  • PreviewDeployednobody has opened it

Nobody Used the Change.

Pie on the same pull request

  1. Opened the Preview
  2. Applied a Promo Code
  3. Went to Payment
Pie PR Botbot
1 of 3 changes verifiedNO-GO
Broken by this PR Discount carries through to paymentThe cart shows $0.00. Payment asks for $42.00.

Caught Before Merge. With a Replay of Every Step.

  • 01

    It Tests What Changed.

    Pie reads the pull request and writes a few checks for it, in plain English. No test scripts to write, no locators to break.

  • 02

    It Uses the App Like a Customer.

    It signs in with your test login, taps, types and reads the screen on your preview: web, iOS or Android.

  • 03

    It Tells You Whose Problem It Is.

    This pull request, existing code, or the preview setup. When Pie can’t be sure, the row says so, and why.

How it works

How to Test a Pull Request Before Merging

Four steps. By hand, someone on your team does them for every pull request. With Pie, you tag it.

  1. 1Run the Change

    By handDeploy the branch to a preview or staging URL.

    PieTakes the URL from your comment or your deploy tool, and waits while it deploys.

  2. 2Sign In Like a Customer

    By handA test account, its data, the feature flag on.

    PieUses the test login you keep in Pie, only while a test runs.

  3. 3Use the Change

    By handApply the code. Pay. Refresh. Try the edge cases.

    PieWrites targeted checks from the diff and runs them on the preview.

  4. 4Say What You Saw

    By handWrite it up on the pull request, with proof.

    PiePosts one comment: a verdict, a row per change, a replay of every test.

Your pace

Why Nobody Clicks Through Every Pull Request.

Checking each one by hand adds up fast, and there are more of them: on teams with high AI adoption, developers merge 98% more pull requests. Faros AI, 2025

min

Sign in, set up, click through, write it down, and again after review changes.

25

hours a week of hands-on checking

63% of one person’s week

$84,500
a year, at your hourly cost

With Pie

Pie tests those 25 pull requests on their previews. Your team reads 25 comments a week and decides what merges.

Book a demo →

Bring your number: 25 pull requests a week.

Hours = pull requests × minutes ÷ 60. A year = hours × hourly cost × 52. A week = 40 hours. We quote Pie separately.

What comes back

A Red X Isn’t an Answer. Every Change Gets One.

Pie tests each change your pull request makes and works out what a result means before it tells you.

  1. Test Pass Verified

    The change works on your preview.

  2. Test Pass Every case reached?No Partly verified

    Names the case the tests didn’t reach.

  3. Test Stopped Why?Preview setup Couldn’t verify

    Fix the setup and rerun.

  4. Test Fail Whose is it?Existing code Possible issue

    Worth a look, not this PR’s doing.

  5. Test Fail Whose is it?This PR Broken by this PR

    The bug is linked once it’s approved as real: steps, screenshots, a replay, and with code access on, a fix pull request.

When the tests pass but miss a case

From one of our own pull requests. Both tests passed, and Pie still wouldn’t call the changes verified.

Problems come first in the comment, so you read what needs you before the ticks. If the preview can’t reach a change at all, the row says Not testable on this preview and what would make it testable.

Pie PR Botbotcommit 3a59b326

Pie Web Functional Testing

0 of 3 changes verifiedINCONCLUSIVE
  • Partly verified Test sidebar shows the saved credential instead of a guessed oneDefault and None states were shown, but no test showed an explicitly saved credential.
  • Partly verified Credential popovers show name and usernameA step-reference popover showed both; one opened from a saved selection was not shown.
  • Not testable on this preview CI runs the new unit testsTo make it testable: run the unit test step in CI.

Both tests passed.

Setup

What You Need to Start: A Preview URL and a Test Login.

  1. Install the Pie app on the repositories you pick.

  2. From your comment, your deploy tool’s link, or a pattern we set up.

  3. With the data it needs and the feature flag on.

  4. Comment @pie-pr-bot test on it, or switch it on for a repository.

  • Web, iOS and Android

    Web previews in a browser; iOS and Android from a simulator or emulator build.

  • GitLab Too

    Comment /pie on the merge request.

  • Behind a Firewall?

    Let Pie’s traffic through, on the preview only.

Customers

Faster Releases, Without Breaking What Works.

Days → Hoursrelease testing
“As we scale our products and offerings it’s really important to make sure we don’t ship something that breaks the existing experience for our users.”
Jonathan Bensamoun Jonathan BensamounCEO, Fi
Read the Fi case study →
0 Manual Regression5 apps · 3 markets
“After evaluating multiple vendors, Pie was the only solution that consistently executed our most complex end-to-end workflows with reliability across builds.”
Anil Kumar LekkalapudiDirector of QA & Automation, Tilt
More customer stories →

Security

Yes, Security Will Ask. Here’s What to Tell Them.

  • Only the Repositories You Pick.You install the Pie GitHub App on the repositories you choose. If your organization restricts third-party apps, an admin approves it.
  • We Never Use Your Source Code to Train AI Models.Source code here means the files and code changes in your repositories.
  • Logins Reach Pie’s Agents Only While a Test Runs.You keep them in Pie’s credential settings.
  • Pie Has a SOC 2 Type 2 Report.Our most recent report is available on request. Data is encrypted in transit.
Security at Pie →

FAQ

Did we miss a question?
Email us directly →

What Is Pull Request Testing?
Testing a change while it’s still a pull request: running it on a preview or staging build and using the app the way a customer would, before the code merges.
How Do You Test a Pull Request Before Merging?
Run the change on a preview, sign in as a test user, use the change and the screens around it, and post what you saw on the pull request. With Pie, you comment @pie-pr-bot test and Pie does the rest, then answers in one comment. Set up pull request testing.
How Is This Different From Code Review or AI Code Review?
Code review reads the diff. Pie runs the app. A reviewer, or a review bot, tells you what the code says; Pie tells you what the app did with your change in it. Keep both.
Do I Need a Preview Environment?
You need somewhere the change is running: a preview for each pull request, or a shared staging build. Pie finds the URL in your comment, in the link your deploy tool posts, or through a pattern we set up with you. More on preview environments.
How Does Pie Sign In and Reach a Feature Behind a Flag?
Give Pie a test account on the preview, with the data it needs and the flag switched on for that account. If the data has to exist first, a setup script can call your test API to create it. More on test data and feature flags.
Does It Work for iOS and Android Apps?
Yes. Pie tests an iOS simulator build or an Android emulator build of the change. Talk to us about getting a build for each pull request to Pie.
Does Pie Test Every Pull Request?
Only where you set it up: when someone tags Pie on a pull request, or automatically in the repositories you switch on. Drafts are skipped.
How Many False Alarms Will We Get?
Pie marks a change Broken by this PR when it traces the failure to your change, and it links the bug once it’s approved as real. Everything else gets a likely cause instead: existing code, or the preview setup. When the tests pass but miss a case, the row says Partly verified and names the case. Each linked bug comes with its steps, screenshots and a replay, so you can check it yourself.
Do We Have to Write or Maintain the Tests?
No. Pie writes the checks for each pull request from its changes. No test scripts to write, no locators to break. If one of Pie's checks is wrong, comment @pie-pr-bot fix-testcase and Pie repairs it.
Will It Slow Our Pipeline?
Pie tests your preview and comments on the pull request when it's done. Your CI runs as it always has.
What Happens After a NO-GO?
Open the replay and the steps, then decide. A NO-GO is Pie’s verdict in a comment; your team decides what merges. If the problem was Pie’s own check, rerun it or tell Pie to fix the check.
Does It Open Fix Pull Requests?
With code access on, Pie opens a fix pull request for a real bug it can fix. Your team reviews it and decides whether to merge.
Does It Work With GitLab?
Yes. Comment /pie on the merge request. GitLab.com connects when you authorize Pie. GitHub and GitLab setup.
How Is It Priced?
Book a demo and we’ll give you a quote after it. It comes down to how many apps you test, how much of each one Pie covers and how many pull requests it tests a week.

Your Next Pull Request Is Already Being Written.

Have Pie test it on your preview before it merges.