End-to-end (E2E) test
A script that drives your real app in a real browser like a user would: click, type, submit, then check what appears on screen.
See it
What it is
An end-to-end test drives your actual running app the way a person would: open the page, type an email, click 'Sign up', wait for the dashboard, check that the welcome text is there. The point is that one complete user-visible flow runs through the whole system you own, usually a real browser against a real server and a real database. Things outside that boundary (the payment provider, the email vendor, an SMS gateway) are often pinned to sandbox modes or controlled fakes so runs stay repeatable. Playwright and Cypress own this space now, with Selenium as the older ancestor.
Use them for the handful of flows that pay the bills: signup, login, checkout, the one form your whole business runs on. Grab elements by role or by a stable data-testid rather than CSS classes, because classes change every time somebody touches the styling. They usually run headless in CI, which is why failures come back as screenshots, traces, and video.
Gotcha: E2E tests are slow, and they sit closer to nondeterminism than anything below them, since every network hiccup and animation timing quirk is fair game. That is exposure, not destiny. Reliable E2E suites exist, and they get there the same way every time: never sleep for a fixed number of seconds, wait for a condition instead; give each run its own data; keep the count small on purpose. Fifty E2E tests that fail randomly teach your team to ignore red, which is worse than having none.
Ask AI for it
Write a Playwright end-to-end test for the signup flow: visit /signup, fill email and password, submit, and assert the user lands on /dashboard with their name visible. Select elements with getByRole and data-testid, never CSS classes. Use auto-waiting assertions instead of fixed timeouts, generate a unique email per run so it is repeatable, and run it headless with trace and screenshot on failure.