What Is End-to-End (E2E) Testing?

End-to-end (E2E) testing checks that a complete user journey works across every layer of an application: the interface, the APIs behind it, the database, and any third-party service the journey touches. An E2E test drives the running application the way a user would and passes only when the whole flow completes.

The three scripts further down this page run one checkout journey in Playwright, Cypress and Selenium. All three passed against a live demo store on October 11, 2026, and each took between 12 and 19 seconds, which is why most teams keep only a few tests at this level.

What Is End-to-End Testing?

End-to-end testing is a software testing method that runs an application with all of its real parts connected and checks that a user journey works from the first step to the last. E2E is the common abbreviation, and the two names mean the same thing.

The name describes the scope. Unit testing checks one function. Integration testing checks that two or three parts talk to each other correctly. An end-to-end test starts where the user starts, in a browser or a mobile app, and follows the request through the front end, the API, the database and outside services such as a payment provider. It then checks what the user sees at the end.

E2E tests usually run last, after unit and integration tests have passed, against a staging or preview environment that mirrors production. They can be run by hand, and most teams automate the journeys they repeat on every release.

How Does End-to-End Testing Work?

An automated E2E test has three parts: a test runner, a real browser or device, and the application deployed with its real dependencies. The runner sends user actions to the browser, the application handles them the same way it would in production, and the test checks the result after each step.

In that journey, logging in exercises the login form, the auth API and the users table. Checking out adds the order API and a payment provider that your team does not own. A defect in any one of those layers fails the test, so E2E testing catches faults that no single-layer test sees, and a failure takes longer to diagnose than a failed unit test.

How far you can trust the result depends on the environment. The tests need a deployed build, seeded data such as a known user and a product in stock, and either real third-party services in sandbox mode or stubs for the ones you cannot call.

What Does an End-to-End Testing Example Look Like?

An end-to-end testing example follows one user journey through the application and checks the result at every step. The journey here is a returning customer buying one product from an online store: log in, search, add to cart, check out.

The test scenario is a registered customer who logs in, searches for a phone, adds it to the cart, pays, and sees an order confirmation. The objective is to prove that the whole purchase works on a deployed build.

E2E vs Integration vs Unit Testing: What Is the Difference?

The three levels differ in how much of the application is running when the test executes. A unit test runs one function, an integration test runs a few connected parts, and an end-to-end test runs the whole deployed application.

The 70/20/10 split in the table comes from Google's testing blog, which offers it as a good first guess and adds that the exact mix will be different for each team.

For the two upper levels side by side, including one behavior automated both ways and timed, see end-to-end testing vs integration testing.

What Are the Types of End-to-End Testing?

End-to-end testing has two types. Horizontal E2E testing follows a user across the screens and applications of a workflow, and vertical E2E testing follows one transaction down through the layers of a single system.

Horizontal tests are the common kind. The checkout journey is one: it moves from login to search to cart to payment the way a customer does, and it may cross into other systems such as an inventory service or a shipping provider. Business users can read and agree on these tests, because each step is something a person does.

Vertical tests take one action, such as placing an order, and check each layer it passes through in turn: the UI, the API response, the row written to the database, the message put on a queue. They need access below the UI, so developers usually write them, and they overlap with integration testing more than horizontal tests do.

When Is End-to-End Testing Worth It?

End-to-end testing is worth it for the few journeys where a failure costs revenue or users and where the failure can only appear when the whole system runs together. For everything else, a lower-level test finds the same defect faster and at lower cost.

An E2E test earns its place when:

• The journey makes money or protects accounts: sign-up, login, checkout, payment, password reset.
• The journey crosses a boundary that lower-level tests mock, such as a payment provider, a single sign-on service or a message queue.
• A past incident got through unit and integration tests because each part worked alone and the combination did not.
• Someone repeats the same manual check before every release.

It is the wrong tool for checking every validation rule, every permutation of input, or logic that lives in one function. Those cases multiply quickly, and each E2E test added to cover them makes the suite slower and more likely to fail for reasons unrelated to the product.

Each E2E test also costs more than a lower-level one. It is slow: the three samples on this page took 12 to 19 seconds each for a four-step journey. It needs a deployed environment with test data. When it fails, the cause could be the product, the test or the environment, so someone has to investigate before the team knows whether a defect exists.

Note: Run your end-to-end suite on 3,000+ browser and OS combinations in the TestMu AI cloud, with no test infrastructure to maintain. Start testing on TestMu AI free

How Do You Write End-to-End Tests?

To write an end-to-end test, pick one journey, prepare an environment with known test data, script the user's actions with a browser automation framework, assert on the result of each step, and run the test in CI on every merge.

• Pick one journey. Start with the flow whose failure would hurt most, and write it down as steps with expected results, as in the checkout test cases.
• Prepare the environment and test data. Deploy the build to staging or a preview environment and seed what the journey needs: a user account, a product in stock, a payment sandbox.
• Script the user's actions. Find elements the way a user does, by role, label or visible text. Selectors tied to CSS classes break when the markup changes.
• Assert on the result of each step. Check what the user would check: the cart shows the product, the URL is the checkout page, the confirmation has an order number.
• Run it in CI. Trigger the test on every merge to the main branch, after unit and integration tests pass, and publish the test report where the team will see a failure.

The three scripts automate the same journey on the TestMu AI ecommerce playground, a public demo store: search for a product, open it, add it to the cart, confirm the cart lists it, and reach the checkout page. Login is left out so the scripts run without an account. All three passed on October 11, 2026 in Chrome 155.

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

test('shopper can search, add to cart and reach checkout', async ({ page }) => {
  await page.goto('https://ecommerce-playground.lambdatest.io/');

  // Search for a product and open it
  await page.getByRole('textbox', { name: 'Search For Products' }).fill('HTC Touch HD');
  await page.getByRole('button', { name: 'Search' }).click();
  await page.getByRole('link', { name: 'HTC Touch HD' }).first().click();

  // Add it to the cart and check the cart page
  await page.getByRole('button', { name: 'Add to Cart' }).click();
  await page.getByRole('link', { name: 'View Cart' }).click();
  await expect(page.locator('#content').getByText('HTC Touch HD')).toBeVisible();

  // Move on to checkout
  await page.locator('#content').getByRole('link', { name: 'Checkout' }).click();
  await expect(page).toHaveURL(/route=checkout\/checkout/);
  await expect(page.getByRole('heading', { name: 'Billing Address' })).toBeVisible();
});

$ npx playwright test --reporter=list
  ✓  1 tests/checkout.spec.ts:3:5 › shopper can search, add to cart and reach checkout (13.7s)
  1 passed (14.4s)

describe('checkout journey', () => {
  it('lets a shopper search, add to cart and reach checkout', () => {
    cy.visit('https://ecommerce-playground.lambdatest.io/');

    // Search for a product and open it
    cy.get('input[name="search"]:visible').type('HTC Touch HD{enter}');
    cy.contains('h4.title a', 'HTC Touch HD').click();

    // Add it to the cart and check the cart page
    cy.get('button.button-cart:visible').click();
    cy.contains('a', 'View Cart').click();
    cy.get('#content').contains('a', 'HTC Touch HD').should('be.visible');

    // Move on to checkout
    cy.get('#content').contains('a', 'Checkout').click();
    cy.url().should('include', 'route=checkout/checkout');
    cy.contains('h4', 'Billing Address').should('be.visible');
  });
});

$ npx cypress run --browser chrome --spec cypress/e2e/checkout.cy.js
  checkout journey
    ✓ lets a shopper search, add to cart and reach checkout (15595ms)
  1 passing (18s)

from selenium import webdriver
from selenium.webdriver.common.by import By
from selenium.webdriver.common.keys import Keys
from selenium.webdriver.support import expected_conditions as EC
from selenium.webdriver.support.ui import WebDriverWait


def test_shopper_can_reach_checkout():
    options = webdriver.ChromeOptions()
    options.add_argument("--headless=new")
    options.add_argument("--window-size=1366,900")
    driver = webdriver.Chrome(options=options)
    wait = WebDriverWait(driver, 15)
    try:
        driver.get("https://ecommerce-playground.lambdatest.io/")

        # Search for a product and open it
        driver.find_element(By.NAME, "search").send_keys("HTC Touch HD", Keys.ENTER)
        wait.until(EC.url_contains("search="))
        wait.until(EC.element_to_be_clickable((By.LINK_TEXT, "HTC Touch HD"))).click()

        # Add it to the cart and check the cart page
        wait.until(EC.url_contains("product_id="))
        wait.until(EC.visibility_of_any_elements_located((By.CSS_SELECTOR, "button.button-cart")))[0].click()
        wait.until(EC.element_to_be_clickable((By.PARTIAL_LINK_TEXT, "View Cart"))).click()
        cart = wait.until(EC.visibility_of_element_located((By.CSS_SELECTOR, "#content table")))
        assert "HTC Touch HD" in cart.text

        # Move on to checkout
        driver.find_element(By.CSS_SELECTOR, "#content a.btn-primary").click()
        wait.until(EC.url_contains("route=checkout/checkout"))
        assert "Billing Address" in driver.find_element(By.TAG_NAME, "body").text
    finally:
        driver.quit()

$ python -m pytest py/test_checkout.py -q
1 passed in 14.71s

How Is AI Changing End-to-End Testing?

An AI testing agent takes the journey as a goal written in natural language, such as "buy one phone as a returning customer", and works out the steps itself. It opens a real browser or device, performs the actions, checks the outcome, and reports a pass or fail. When a button moves or a label changes, the agent can find the element again from the goal, where a scripted test would stop on a missing selector.

KaneAI is TestMu AI's end-to-end testing agent. You author a test in natural language, and when the UI shifts and locators change, it updates the affected steps and shows the diff for review. Kane CLI brings it to the terminal, so developers and coding agents can verify a change in a real browser and read back a pass or fail. Agents suit journeys that change often, and a hand-written script still fits where every step has to be fixed and reviewed in code. For more on agent-based testing, see KaneAI E2E testing agent. Testing an AI agent itself is a separate job, covered in end to end agent testing.

In the TestMu Conf 2026 session The Last Manual Handoff: Redesigning End-to-End Testing in the Age of AI, Sachin Sharma looks at why E2E testing still feels manual after teams have automated execution, regression, reporting, data creation and test design.

What Are End-to-End Testing Best Practices?

Good end-to-end tests are few, independent of each other, and stable enough that a failure means a defect. Most of the practices here exist to prevent flaky tests, which pass and fail on the same code.

• Test journeys and leave edge cases to lower levels. Cover the common path through each business-critical flow. Input validation and error branches belong in unit and integration tests.
• Wait for conditions, never for time. A fixed sleep is too short on a slow day and wasted on a fast one. Wait for a URL, an element or a network response, as the Selenium script does.
• Use locators a user would recognize. Roles, labels and visible text survive a redesign better than generated class names. Make each locator match one element: the Playwright run failed until its cart check stopped matching two links.
• Give every test its own data. A test that depends on an order created by another test fails when the two run in parallel or in a different sequence. Create what the test needs at the start, through the API where possible.
• Pair E2E with API tests. When a journey fails, API testing on the same endpoint tells you whether the fault is in the front end or behind it.
• Run on the browsers and devices your users have. A journey that passes in Chrome can fail in Safari or on a small Android screen. Running the suite in parallel in a cloud keeps that coverage from slowing the pipeline.
• Quarantine a flaky test the day it flakes. Move it out of the blocking suite, fix the cause, then put it back. Once people rerun a failed pipeline out of habit, real failures get rerun too.

Which Tools Do You Need for End-to-End Testing?

You need a framework to drive the browser and somewhere to run it. An agent that writes and maintains tests is optional. For a list of options, see end-to-end testing tools.

• Playwright drives Chromium, Firefox and WebKit from one API, with auto-waiting and a trace viewer for failed runs.
• Cypress runs inside the browser beside the application and shows each command in an interactive runner. See the Cypress tutorial.
• Selenium implements the W3C WebDriver standard, with bindings for Java, Python, C#, Ruby and JavaScript.
• Puppeteer controls Chrome and Firefox from Node.js. See the Puppeteer tutorial.

TestMu AI runs suites written in any of these frameworks in the cloud, on 3,000+ browser and operating system combinations and 10,000+ real iOS and Android devices. HyperExecute splits a suite across machines to shorten the run.

For AI-based options, see the roundup of ai testing tools. To automate a whole journey from one natural language objective without scripting each step, see end-to-end flow automation.

Where Should You Start With End-to-End Testing?

Start with one journey: the flow that would cost the most if it broke tonight. Write its test cases as a table, automate it with the framework your team already knows, and run it on every merge. Add a second journey once the first has stopped producing false failures.