Short answer
End-to-end testing checks a complete user journey through your running app, from the first click to the final result, the way a real user would: sign in, add an item to the cart, pay, and see the order confirmation. It catches the bugs that only show when the front end, back end, database and third-party services work together. You can write E2E tests in code with Playwright or Cypress, build them in a low-code tool, or let an AI agent such as TestOptim AI explore the app and write them.
- An E2E test drives a real browser against a running app; unit tests check one function in isolation.
- E2E tests are slower and break more easily than unit tests, so keep them for the journeys that matter most.
- Most E2E failures come from test maintenance, not from real bugs; choose tools that reduce that work.
- Run them on staging before every release, and on a schedule to catch problems from third-party changes.
On this page
What is end-to-end testing?
A web app is many parts: the pages in the browser, an API, a database, and services such as payments and email. Each part can pass its own tests and the app can still be broken, because the bug is in how they connect. A sign-up form that saves the user but never sends the confirmation email is a classic example.
End-to-end testing, often shortened to E2E testing, checks the whole chain at once. A test opens the app in a real browser, acts like a user, and checks what the user would see at the end. If anything in the chain is wrong, the result is wrong, and the test fails.
End-to-end testing vs unit and integration testing
| Unit test | Integration test | End-to-end test | |
|---|---|---|---|
| What it checks | One function or component | Two or more parts together, such as an API and its database | A full user journey through the running app |
| Runs in | Memory, in milliseconds | A test environment, in seconds | A real browser against staging, in seconds to minutes |
| Catches | Logic errors | Contract and data errors between parts | Anything a user would notice |
| Breaks when | The code's behaviour changes | An interface changes | The UI, data or any service changes |
| How many to have | Many | Some | A focused set of key journeys |
This is the testing pyramid: many fast unit tests at the bottom, fewer slow E2E tests at the top. Small teams often have the opposite problem, no tests at all, and a small E2E suite over the main journeys gives them the most protection for the effort.
An end-to-end test example
Here is a test for an online store, written as plain-English steps the way TestOptim AI stores it. A coded version in Playwright would do the same steps with selectors.
- Sign in as the test shopper.
- Search for 'blue mug' and open the first result.
- Add two to the cart, then remove one.
- Check that the cart shows one blue mug and the right total.
- Check out with the test card and confirm the order page shows an order number.
The expected result is what makes it a test: one item, the right total, an order number. Our test case generator drafts cases like this from a short description of a feature.
Three ways to build E2E tests
- Write them in code. Playwright, Cypress and Selenium give full control and keep tests in your repository. Someone writes and fixes every test, and selectors break when the markup changes. See Playwright alternatives.
- Build them in a low-code tool. Record flows or write steps in an editor. Faster to build, but someone still decides what to test and updates each case. See low-code test automation tools.
- Let an AI agent write them. AI test automation explores the app, writes the cases and runs them. TestOptim AI stores no selectors, so markup changes don't break the tests.
End-to-end testing tools
| Tool | Explores your app on its own | Plain-English test cases | Self-healing tests | CI/CD and scheduled runs | Test code you own and export | Pricing |
|---|---|---|---|---|---|---|
| Momentic | Yes | Yes | Yes | Yes | Partly | Free ($50 of usage/mo); paid from $500/moChecked 9 Nov 2026 |
| TestOptim AI | Yes | Yes | Yes | Yes | No | 7-day Solo trial, then $19–$149/mo self-serve |
| QA Wolf | Yes | Not verified | Yes | Yes | Yes | $1 per web test run ($2 mobile or desktop)Checked October 2026 |
| testRigor | No | Yes | Yes | Yes | No | Free for public projects; private plans by quoteChecked 26 Oct 2026 |
| Cypress | No | Partly | Not verified | Yes | Yes | Free app; Cloud free on Starter, then from $67/mo (annual)Checked 20 Oct 2026 |
| Playwright | Partly | Partly | Partly | Yes | Yes | Free, open sourceChecked 20 Oct 2026 |
| Selenium | No | No | No | Yes | Yes | Free, open sourceChecked 20 Oct 2026 |
For more tools with who each suits and what it can't do, see test automation tools compared.
End-to-end testing best practices
- Test journeys, not pages. Each test should end with a result a user cares about: an order placed, an invite accepted, a report exported.
- Use a staging copy with test data. E2E tests create and delete records. Keep them away from production.
- Give each test its own data. Tests that share an account fail in random order and are hard to debug.
- Check visible results, not internals. Assert on what the user sees, so a refactor does not break the test.
- Keep evidence for every failure. A screenshot, a video and a trace save hours of 'works on my machine'.
- Run them before every release and on a schedule. A daily run catches breakage from third-party changes too. See Schedule test runs.
A flaky test, one that passes and fails without a code change, costs more than it saves. Fix or remove it quickly, or the team learns to ignore red builds.
End-to-end testing with TestOptim AI
Give TestOptim AI your staging URL and a test login. Its agent explores the app in a real browser, saves the pages, flows and entities it finds, and generates E2E test cases for them in plain English. Each run uses a fresh browser and turns every defect into an issue with severity, steps to reproduce and a screenshot, while the run keeps a video and a Playwright trace. Start runs by hand, on a schedule or from CI with an API key.
Frequently asked questions
What is an example of end-to-end testing?
Signing in, adding an item to the cart, paying with a test card and checking that the order page shows an order number. The test passes only if the browser, API, database and payment service all work together, which is what makes it end to end.
Who is responsible for end-to-end testing?
In larger companies, QA engineers or SDETs write and maintain the suite. In small teams it usually falls to developers, which is why it gets skipped. An AI agent can take over the writing and running, leaving a developer to review the bugs it reports.
How many end-to-end tests should an app have?
Enough to cover every journey that would cost you users or money if it broke: sign-up, sign-in, the core feature, billing and settings. For a small app that is often a few dozen cases, with more for edge cases where bugs have happened before.
Why are end-to-end tests flaky?
Most flakiness comes from timing, shared test data and selectors that match the wrong element after a UI change. Waiting on visible results, giving each test its own data, and avoiding stored selectors removes most of it.
Can end-to-end tests run in CI/CD?
Yes, and they should run before every deploy to production. Coded frameworks run inside your CI job. TestOptim AI runs in its own browsers: CI starts the run with an API key and fails the build on critical or high issues.
Is end-to-end testing the same as UI testing?
Not quite. UI testing checks that the interface looks and behaves right, and can stop at the front end. End-to-end testing uses the UI to drive a full journey and checks the result across every part of the system, including the server and database.
Related reading
- AI test automationHow an agent explores your app, writes E2E tests and runs them.
- Automated regression testingRe-run your E2E suite on every release without doing it by hand.
- Test automation tools comparedCoded frameworks, low-code platforms and AI agents in one list.
- Docs: read test run resultsSteps, screenshots, recordings and traces for every run.