What is end-to-end testing?
The test that behaves like a customer. Here is where it fits beside the faster tests underneath it.
In short
End-to-end testing checks a complete user journey through the running application the way a customer would, with a script driving a real browser to sign up, create something, pay and see the result. It touches the interface, server, database and outside services together. Playwright and Cypress automate it.
Also called: E2E testing, E2E tests, Browser testing
Which user journeys should an end-to-end test cover?
The journeys that make you money, sign-up, onboarding, checkout, are exactly the ones nobody re-tests by hand after every change, because they take too long. An end-to-end test does it in minutes on every release, and tells you the day a change breaks the path customers pay through.
| Test | What it checks | Speed | How many |
|---|---|---|---|
| Unit | One function on its own | Milliseconds | Many |
| Integration | Parts together, such as code and a real database | Seconds | Some |
| End-to-end | A whole journey in a browser | Seconds to minutes | A few, on key paths |
End-to-end tests are the slowest and most brittle kind, so keep them for the journeys that matter most, and cover the detail with faster tests underneath. Zulu, for instance, runs most of its test files against a real PostgreSQL engine rather than a mock.
How many end-to-end tests does a real product need?
Fewer than you might expect, aimed at the journeys that make money or lose trust. The unit and integration tests do most of the checking, quickly and precisely; the end-to-end journeys prove the assembled system works where users meet it, on real infrastructure rather than a developer's laptop.
Because they run against a deployed copy, they also catch problems no code-level test sees: a missing secret, a wrong address setting or a service that did not start. Keep the set small, stable and focused on the paths that matter.
How do you start end-to-end testing a Lovable app with Playwright?
Start with one journey, sign-up to the first useful action, against a staging environment rather than production. Playwright installs with npm init playwright@latest, downloads its own browsers, and runs tests headless by default across Chromium, Firefox and WebKit, in parallel. Its installer can also add a GitHub Actions workflow to run them in CI.
- Use test accounts and test payment modes, never real customer data.
- Run the journeys on every release in your CI/CD pipeline, after the faster tests pass.
- When a journey fails, reproduce the bug in a smaller test before fixing it, as Martin Fowler's test pyramid advises, so it stays fixed.
The common mistake is the opposite pyramid: hundreds of browser tests and few fast ones. Fowler notes that tests run through the interface are slow, brittle and prone to random failures, so a team stops trusting them. If your app has no tests at all yet, our production readiness check shows where to begin.
Common questions
Is end-to-end testing the same as integration testing?
No. Integration tests check that some parts work together, such as code and a real database. End-to-end tests check the whole journey through the running app, usually in a browser. Keep end-to-end tests for key paths, since they are slower, and let integration tests cover the detail.
Is Playwright an end-to-end testing tool?
Yes. Playwright drives real Chromium, Firefox and WebKit browsers on Windows, Linux and macOS, and is widely used for end-to-end tests, as is Cypress. A Playwright script can sign up, create something, pay and check the result, touching every layer of the app together.
Why are end-to-end tests flaky?
They depend on everything at once: the browser, the network, the server, the database and outside services, any of which can be slow or briefly unavailable. Martin Fowler's test pyramid calls them brittle and prone to non-determinism. Keep them few, and use stable test data and environments.
Go deeper
How to test an AI-built app before launchHow to test a Lovable or AI-built app before launch: which journeys to test first, two-account access checks, payment failures, and tests on every change.
Related terms
Sources
- Playwright documentation
- Martin Fowler: Test Pyramid (May 1, 2012)
- Cypress documentation: Testing types
Sources checked October 24, 2026
More on this: Production architecture & security · All glossary terms
Built something in Lovable you want people to rely on?
We are the engineers who take it the rest of the way — secured, tested, released and supported.
