ReviseAlgo Logo

Testing JavaScript

End-to-End Testing with Playwright/Cypress (Overview)

Master End-to-End testing in JavaScript. Learn browser automation basics, selector queries, user interaction simulation, and assertions.

Last Updated: July 15, 2026 • 10 min read

1. Introduction

End-to-End (E2E) Testing validates your application's entire workflow by launching actual browsers, loading pages, and automating user actions (like filling inputs, clicking buttons, and scrolling pages) to verify behavior.

2. Why It Matters

Unit and integration tests run inside simulated terminal environments (like jsdom), which can differ from real browsers. E2E tests validate that your CSS compiles correctly, buttons are clickable (not obscured by overlays), and pages load and interact correctly in actual browsers.

3. Real-World Analogy

Think of a Secret Shopper (E2E Test):

  • Internal Audits (Unit/Integration): The store manager checks the inventory ledger and updates log files. Everything looks correct on paper.
  • Secret Shopper: A person walks through the front door, browses the aisles, picks up a product, asks a question, checks out at the register, and walks out. Symmetrically, they test the actual shopping experience in real-world conditions, catching real-world issues (like blocked aisles or rude service) that ledger books miss.

4. Playwright Basics

Playwright is a modern browser automation library developed by Microsoft. It runs fast, supports parallel execution, and handles chromium, WebKit (Safari), and Firefox browsers:

5. Cypress Basics

Cypress is another popular E2E testing library. It runs inside the browser context alongside your application, offering excellent debugging tools:

6. Practical Example

This script demonstrates using Playwright to test an interactive search query list with automated network intercepts:

7. Common Mistakes

  • Using brittle element selectors: Referencing elements using generic class selectors (like .btn-primary or div > span > button) makes tests brittle. If you modify your CSS layouts, the tests will fail. Use resilient selectors like data-testid attributes or accessible role queries (like page.getByRole('button', { name: 'Submit' })) instead.

8. Quick Quiz

Q1: Why should you avoid using CSS layout hierarchy pathways (e.g. 'div > button') inside E2E selectors?

A) Because they consume more CPU and slow down testing speed

B) Because they bind tests to the visual layout, meaning any HTML/CSS restructure will break the tests

Answer: B — Layout selectors bind tests to CSS structures. Using test-ids or ARIA roles keeps selectors resilient to layout changes.

9. Scenario-Based Challenge

The E2E Purchase Flow Validation:

An e-commerce app requires testing: user selects a product, adds it to the cart, navigates to checkout, fills card data, and receives a receipt. Write a Playwright script outline to automate this flow from catalog to order confirmation screen.

10. Debugging Exercise

Explain why this E2E test randomly fails, and how to fix it:

test('loads products page', async ({ page }) => {
  await page.goto('/products');

// Bug: querySelector returns immediately, but products load asynchronously!
  const list = page.locator('.product');
  expect(await list.count()).toBe(10); // Randomly fails if query executes before API resolves!
});
View Solution

Diagnosis: The test asserts the list count immediately after navigating. Since products are loaded asynchronously via API calls, the assertion will fail if the query executes before the API request completes (known as a race condition in E2E tests).

Fix: Use Playwright's built-in wait methods or assertions, which automatically poll the DOM and wait for elements to appear before running assertions:

test('loads products page', async ({ page }) => {
  await page.goto('/products');


const list = page.locator('.product');
  // Playwright expect assertions automatically wait for elements to appear!
  await expect(list).toHaveCount(10); 
});

11. Interview Questions

🟢 Q1: What is the benefit of auto-waiting in modern E2E frameworks like Playwright?

Answer: Early automation tools (like Selenium) required developers to manually write sleep triggers (e.g. sleep(2000)) to wait for pages to load. This made tests slow and brittle.
Modern E2E frameworks (like Playwright or Cypress) implement Auto-waiting. Before performing actions (like clicking a button or reading text), the framework automatically checks if the element is visible, stable, enabled, and clickable. This prevents race conditions and makes tests more resilient.

12. Production Considerations

  • • Parallel Runs: E2E tests are slow. In your CI/CD pipelines, configure Playwright to run tests in parallel across multiple worker threads or browser instances to reduce build times.