End-to-End Testing

What it is

An end-to-end (E2E) test exercises the entire system the way a user does: real browser, real frontend, real backend, real database. Nothing is mocked. It is the highest confidence and the highest cost test you can write — slow, and prone to flakiness.

Because it is expensive, keep the E2E layer thin: cover only the journeys that must never break (signup, login, checkout, payment), not every variation.

When to use it / when to avoid it

Use it for

Critical user journeys end to end
Wiring across the full stack (browser → API → DB → back)
Smoke checks after deployment

Avoid it when

The same behaviour can be covered more cheaply by a component or integration test
You are tempted to use E2E to test validation rules — that belongs lower

Frameworks & tools

Tool	Ecosystem	Notes
Playwright	Multi	Cross-browser, auto-wait, tracing, codegen
Cypress	Multi	Great DX, time-travel debugging
Selenium	Multi	The original; WebDriver standard
WebdriverIO	Node	Flexible WebDriver/DevTools runner
Puppeteer	Node	Chromium/Firefox control
TestCafe	Node	No WebDriver, easy setup
Robot Framework + SeleniumLibrary	Python	Keyword-driven E2E, also RPA
Nightwatch	Node	WebDriver-based

Quick setup

1
npm init playwright@latest
2
npx playwright test
3
npx playwright test --ui

1
npm install -D cypress
2
npx cypress open

1
pip install selenium

1
pip install robotframework robotframework-seleniumlibrary
2
robot tests/

1
npm init wdio@latest .

Example

1
import { test, expect } from '@playwright/test';
2

3
test('user can sign up and reach the dashboard', async ({ page }) => {
4
  await page.goto('/signup');
5
  await page.getByLabel('Email').fill('ada@example.com');
6
  await page.getByLabel('Password').fill('s3cret');
7
  await page.getByRole('button', { name: 'Create account' }).click();
8

9
  await expect(page.getByRole('heading', { name: 'Dashboard' }))
10
    .toBeVisible();
11
});

1
it('signs up and reaches the dashboard', () => {
2
  cy.visit('/signup');
3
  cy.findByLabelText('Email').type('ada@example.com');
4
  cy.findByLabelText('Password').type('s3cret');
5
  cy.findByRole('button', { name: /create account/i }).click();
6
  cy.findByRole('heading', { name: /dashboard/i }).should('be.visible');
7
});

1
*** Settings ***
2
Library    SeleniumLibrary
3

4
*** Test Cases ***
5
Dang Ky Va Vao Dashboard
6
    Open Browser    ${BASE_URL}/signup    chrome
7
    Input Text      id=email             ada@example.com
8
    Input Text      id=password          s3cret
9
    Click Button    Create account
10
    Wait Until Page Contains    Dashboard
11
    [Teardown]      Close Browser

1
def test_signup(driver, base_url):
2
    driver.get(f"{base_url}/signup")
3
    driver.find_element("id", "email").send_keys("ada@example.com")
4
    driver.find_element("id", "password").send_keys("s3cret")
5
    driver.find_element("css selector", "button[type=submit]").click()
6
    assert "Dashboard" in driver.page_source

Anti-patterns & best practices

Keep the suite small. Cover journeys, not permutations. Push detail down the pyramid.
Use resilient locators. Prefer roles and labels over brittle CSS/XPath.
Never use fixed sleeps. Use auto-waiting (expect(...).toBeVisible()), not sleep(3).
Isolate state. Each test creates its own data so order does not matter.
Capture artifacts on failure. Screenshots, video and traces turn a red run into a diagnosable one.
Run in parallel in CI and quarantine genuinely flaky tests rather than ignoring red.