Buy trail runners with a promo code
The bug between steps
Every Step Worked. The Setting Never Saved.
Catch the bugs that live between steps. Pie walks the whole journey the way your customer does. This one is real, from a demo app we test with.
- Enter the registered email address in the email field
- Enter the password in the password field
- Tap the ‘Sign in’ button
- Tap ‘My preferences’ from the bottom of the sidebar menu
- Tap on ‘Notifications’ within the preferences menu
- Tap the checkbox for the first notification preference in the list
- Scroll to the bottom of the page
- Tap the ‘Save preferences’ button
- Refresh the browser page
- Check that the preference remains enabled after refreshing
PassedAfter Save, the box is ticked.
FailedAfter a refresh, it isn’t.
When your app changes
Pie Reads the Screen. Not Your Selectors.
Stop repairing tests every time the screen moves. Pie reads the screen on every run, so a renamed button or a surprise pop-up doesn’t have to stop the test.
Your cart
Trail runner, size 9$42.00
BIGSAVE50−$21.00
Total$21.00
Continue to paymentIt used to say Checkout.
Your cart
Trail runner, size 9$42.00
BIGSAVE50−$21.00
Total$21.00
CheckoutYour cart
Trail runner, size 9$42.00
BIGSAVE50−$21.00
It moved to a bar at the bottom.
CartShippingPayment
Shipping address
12 Trail Way
ContinueA new page before payment.
A Playwright script
await page
.getByRole('button',
{ name: 'Checkout' })
.click(); FailedTest timeout of 30000ms exceeded.
Someone edits the script.
Failed<div class="promo"> intercepts pointer events
Someone adds a handler for the pop-up.
Passed
Same name, so it still finds the button. A good script handles a move.
FailedNext line: getByLabel('Card number') timed out.
Then the payment page isn’t there. Someone rewrites the test.
Pie’s test step
Go to payment
Passed
Pie finds the button by its context, position and function.
Passed
Pie reads the screen, works through the pop-up and carries on.
Passed
Pie finds the button in its new place.
Failed
A change this big can fail the step. Tell Pie and it fixes the test.
A sample store and a sample script. If a button’s ID or text changes, Pie can still find the right element. A redesign that changes the journey can need the steps updated.
Scripts or Pie
Playwright Is Free. The Upkeep Isn’t.
Get your upkeep hours back. Every script is code your team writes, reviews and repairs. Hand the journeys to Pie and that time goes into your product.
| Playwright or Cypress | Pie | |
|---|---|---|
| License | Free and open source.Their edge | Paid. You get a quote after a demo. |
| Cost to run | Your team’s hours to write, review and repair scripts, plus the CI to run them. | No scripts to write, no locators to break. Your team makes the calls, and the rest of those hours go into your product.Pie’s edge |
| Who writes it | Your team, in code. | Pie explores your app and generates tests, or drafts one from your description. Your team reviews them.Pie’s edge |
| When the UI moves | A locator that stops matching fails the run until someone fixes it. | Pie re-reads the screen on every run.Pie’s edge |
| iOS and Android | Built for the browser. A native app means a second framework, usually Appium. | Web, iOS and Android, from one place.Pie’s edge |
| Test code | Every test is code in your repository.Their edge | Tests live in Pie in plain English, with an API and an MCP server. |
“We started some end to end tests, technical tests, and after a few months without maintaining them, they don’t work anymore.”A buyer on a call with us
Stay on scripts if you want every test as code in your repository, or a handful of scripts covers your app. Moving is one journey at a time.
Your tests, your call
You Can Read Every Test. And Change Any of Them.
Always know what’s being checked. Pie drafts your tests in plain English, from your description or by exploring your app, and your team sets when they run.
- Plain English, no code.Anyone on your team can read a test and check it.
- Wrong? Tell Pie.It fixes the test in your draft. Nothing changes until you save.
The basics
New to End-to-End Testing? Start Here.
Get up to speed in eight short answers, from what it is to which tools to look at. The guides go deeper.
End-to-end testing walks a whole journey the way your customer takes it, from the first screen to the result they came for. Sign in, search, add to cart, pay, find the order.
It checks that the parts work together, which tests of one part at a time can’t see.
Our end-to-end testing guide covers the types and how to set one up.
A customer ticks a notification setting, presses Save and refreshes the page. The box ticks, the button presses and the page comes back, and the setting is gone anyway. That’s the real bug at the top of this page.
For a longer one, see how to test payment and checkout flows end to end.
A unit test checks one piece of code. An integration test checks that two parts talk to each other, like your checkout service and your payment provider. An end-to-end test drives the app through its real screens and checks what the customer ends up with.
Keep your unit and integration tests. They’re fast and they belong in your code. The end-to-end test catches what sits between the parts.
User acceptance testing asks whether the software does what the business asked for, and people usually do it before a release.
End-to-end testing checks that a journey works from start to finish, and it’s usually automated so it can run again on every release.
Those name when a test runs. End-to-end names how far it walks.
Regression testing re-checks what already worked, smoke testing asks whether a new build works at all, and pull request testing asks whether one change broke something. An end-to-end test can sit in any of them.
Pie runs all three.
Start with the journeys that cost you most when they break, usually sign-up, login, checkout and payments.
Then add the ones that are hardest to script, like one-time codes, SSO, roles and permissions, multi-step forms and feature flags.
Keep the small edge cases in faster tests and save these for what your customer actually does.
Timing, stale selectors, shared test data and things nobody planned for, like a pop-up. Long journeys flake the most, so teams split them up and lose the journey.
In a 2024 study of one commercial project, with about 30 developers over five years, flaky tests alone took at least 2.5% of their productive time.
Flaky tests, explained covers the causes, and here’s why mobile end-to-end tests flake.
Playwright and Cypress are free and exact, and your team writes and maintains the code. An agent like Pie runs tests written in plain English, with no locators to break.
Our list of the best end-to-end testing tools compares them, and Pie vs Playwright goes row by row.
Customers
Complex Workflows. Reliable Across Builds.
“After evaluating multiple vendors, Pie was the only solution that consistently executed our most complex end‑to‑end workflows with reliability across builds.”
“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.”
Security
Yes, Security Will Ask. Here’s What to Tell Them.
- You Pick the Test Account.Pie signs in with the test login you give it. A setup script can call your test API to create the data first.
- 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.