E2E testing with Playwright in NextJS - Deep Dive

Overview - E2E testing with Playwright

What is it?

E2E testing with Playwright means checking if a whole web app works correctly by simulating real user actions like clicking buttons and filling forms. Playwright is a tool that helps automate these tests across different browsers. It runs tests from start to finish, making sure all parts of the app work together as expected. This helps catch bugs before users see them.

Why it matters

Without E2E testing, bugs can slip into the live app, causing users frustration or broken features. Playwright makes it easier to test complex user flows automatically and reliably across browsers. This saves time and effort compared to manual testing and helps keep the app stable and trustworthy. Without it, developers might miss critical issues that only appear when all parts interact.

Where it fits

Before learning E2E testing with Playwright, you should know basic JavaScript, Next.js app structure, and how to write simple tests. After mastering Playwright, you can explore continuous integration to run tests automatically on code changes and advanced testing strategies like mocking and performance testing.

Mental Model

Core Idea

E2E testing with Playwright is like having a robot user that clicks, types, and navigates your app exactly as a real person would, checking everything works from start to finish.

Think of it like...

Imagine testing a new coffee machine by going through every step yourself: adding water, coffee, pressing buttons, and tasting the coffee. Playwright is like a robot that does all these steps for you, making sure the machine works perfectly every time.

┌─────────────────────────────┐
│       Playwright Robot      │
├─────────────┬───────────────┤
│ Browser 1   │ Browser 2     │
│ (Chromium)  │ (Firefox)     │
├─────────────┴───────────────┤
│  Simulates user actions      │
│  Click, type, navigate       │
├─────────────────────────────┤
│  Checks app behavior & UI    │
└─────────────────────────────┘

Build-Up - 8 Steps

1

Foundation

What is E2E Testing

Concept: E2E testing checks if the whole app works by simulating real user actions.

E2E stands for end-to-end. It means testing the app from the user's point of view, clicking buttons, filling forms, and navigating pages. Unlike unit tests that check small parts, E2E tests check the entire flow to catch bugs that happen when parts interact.

Result

You understand that E2E tests simulate real user behavior to verify app functionality.

Understanding that E2E tests cover the full user journey helps you see why they catch bugs missed by smaller tests.

2

Foundation

Introducing Playwright Tool

Concept: Playwright is a tool that automates browsers to run E2E tests across multiple browsers.

Playwright controls browsers like Chromium, Firefox, and WebKit automatically. It can open pages, click buttons, type text, and check what appears on screen. It works with JavaScript and integrates well with Next.js apps.

Result

You know Playwright can run tests that mimic user actions in different browsers.

Knowing Playwright supports multiple browsers ensures your app works well everywhere users visit.

3

Intermediate

Setting Up Playwright in Next.js

🤔Before reading on: do you think Playwright requires complex setup or just a few commands? Commit to your answer.

Concept: You learn how to install Playwright and configure it to test a Next.js app.

To start, install Playwright with npm. Then run 'npx playwright install' to get browser binaries. Create a test folder and write simple tests that open your Next.js app pages and check content. Playwright's config file lets you customize browsers and test options.

Result

You have a working Playwright setup ready to run tests on your Next.js app.

Understanding the simple setup process lowers the barrier to adding reliable E2E tests early in development.

4

Intermediate

Writing Basic Playwright Tests

🤔Before reading on: do you think Playwright tests look like normal JavaScript functions or special scripts? Commit to your answer.

Concept: Learn how to write tests that open pages, click buttons, and check text using Playwright's API.

A test uses 'test' and 'expect' from Playwright test library. You open a page with 'page.goto()', click with 'page.click()', and check text with 'expect(page.locator()).toHaveText()'. Tests run automatically and report success or failure.

Result

You can write simple tests that simulate user actions and verify UI changes.

Knowing Playwright uses familiar JavaScript syntax makes writing tests approachable and flexible.

5

Intermediate

Running Tests Across Browsers

🤔Before reading on: do you think Playwright runs tests in only one browser or multiple by default? Commit to your answer.

Concept: Playwright can run the same tests in Chromium, Firefox, and WebKit to ensure cross-browser compatibility.

Configure Playwright to run tests in different browsers by setting projects in the config file. When you run tests, Playwright launches each browser and runs all tests, reporting results separately. This helps catch browser-specific bugs.

Result

You can verify your Next.js app works consistently across major browsers.

Understanding cross-browser testing prevents surprises when users use different browsers.

6

Advanced

Handling Authentication in Tests

🤔Before reading on: do you think tests should log in every time or reuse login state? Commit to your answer.

Concept: Learn how to manage login flows efficiently by saving and reusing authentication state in Playwright tests.

Logging in via UI every test is slow. Playwright lets you save storage state (cookies, localStorage) after login and reuse it in tests. This speeds up tests and avoids flaky login steps. You create a login script once, save state, then load it in other tests.

Result

Tests run faster and more reliably by reusing login state instead of repeating login steps.

Knowing how to reuse authentication state improves test speed and stability in real-world apps.

7

Advanced

Debugging and Test Reporting

🤔Before reading on: do you think Playwright provides tools to watch tests run or only text reports? Commit to your answer.

Concept: Explore Playwright's debugging tools and rich reports to find and fix test failures quickly.

Playwright offers a headed mode to watch tests run in a real browser window. It also records videos and screenshots on failure. The HTML report shows test results with details and logs. You can use 'page.pause()' to stop tests and inspect the app state.

Result

You can debug tests visually and understand failures faster.

Using Playwright's debugging features reduces frustration and speeds up fixing test issues.

8

Expert

Advanced Test Architecture and Parallelism

🤔Before reading on: do you think running many tests in parallel is always safe or can cause problems? Commit to your answer.

Concept: Learn how to organize tests for speed and reliability using parallel runs, test isolation, and shared fixtures.

Playwright runs tests in parallel by default to save time. But tests must not share state or interfere with each other. Use fixtures to set up fresh app state per test. Split tests logically and avoid dependencies. Configure retries and timeouts for flaky tests. This architecture scales well in CI pipelines.

Result

Your test suite runs fast, reliably, and scales with your app growth.

Understanding test isolation and parallelism is key to maintaining a healthy, fast E2E test suite in production.

Under the Hood

Playwright works by launching real browser instances controlled via a protocol. It sends commands like 'click' or 'type' to the browser engine, which executes them exactly as a user would. It listens for events like page loads or element changes to verify app state. Playwright manages multiple browsers and contexts to isolate tests and runs them in parallel for speed.

Why designed this way?

Playwright was built to solve limitations of older tools that only supported one browser or used slow, brittle automation. By controlling browsers at a low level with a unified API, it ensures tests are fast, reliable, and cross-browser. This design balances power and simplicity, making it easy to write realistic tests that catch real bugs.

┌───────────────┐       ┌───────────────┐
│ Playwright    │──────▶│ Browser 1     │
│ Test Runner   │       │ (Chromium)    │
├───────────────┤       └───────────────┘
│ API Commands  │
│ (click, type) │       ┌───────────────┐
│ Listeners    │◀──────│ Browser 2     │
│ (events)     │       │ (Firefox)     │
└───────────────┘       └───────────────┘
         │
         ▼
┌─────────────────────────────┐
│ Test Results & Reports       │
└─────────────────────────────┘

Myth Busters - 4 Common Misconceptions

Quick: Do you think E2E tests replace unit and integration tests? Commit yes or no.

Common Belief: E2E tests are enough alone; no need for unit or integration tests.

Reality: E2E tests complement but do not replace unit or integration tests. They are slower and catch different issues.

Why it matters: Relying only on E2E tests slows development and makes debugging harder because failures are less specific.

Quick: Do you think Playwright tests run instantly without setup? Commit yes or no.

Common Belief: Playwright tests run instantly and don't need any setup or configuration.

Reality: Playwright requires setup like installing browsers and configuring tests to run properly.

Why it matters: Skipping setup causes tests to fail or behave unpredictably, wasting time and causing frustration.

Quick: Do you think tests can share login state safely without issues? Commit yes or no.

Common Belief: Tests can share login state freely without causing flaky or failing tests.

Reality: Sharing login state without isolation can cause tests to interfere and fail unpredictably.

Why it matters: Not isolating state leads to flaky tests that are hard to trust and maintain.

Quick: Do you think running many tests in parallel never causes problems? Commit yes or no.

Common Belief: Running tests in parallel is always safe and speeds up testing without downsides.

Reality: Parallel tests can cause conflicts if they share state or resources, leading to flaky failures.

Why it matters: Ignoring test isolation in parallel runs causes unreliable test results and wasted debugging time.

Expert Zone

1

Playwright's browser contexts isolate sessions better than opening new browser instances, saving resources and speeding tests.

2

Using selectors wisely (like data-testids) improves test stability and reduces brittleness caused by UI changes.

3

Playwright supports network interception to mock API responses, enabling faster and more reliable tests without backend dependencies.

When NOT to use

Playwright is not ideal for testing backend logic or APIs alone; use unit or integration tests instead. For simple UI checks, lighter tools or snapshot tests may be faster. Also, if your app heavily relies on third-party widgets that are hard to control, consider mocking or isolating those parts.

Production Patterns

In production, Playwright tests run in CI pipelines on every code push to catch regressions early. Teams organize tests by feature and use tagging to run critical tests on every commit and full suites nightly. They combine Playwright with visual regression tools and performance monitoring for comprehensive quality assurance.

Connections

Continuous Integration (CI)

Builds-on

Knowing how Playwright tests run automatically in CI helps ensure code changes don't break the app before deployment.

User Experience (UX) Design

Related domain

Understanding user flows tested by Playwright connects to UX design by verifying that the app behaves as users expect.

Robotics Automation

Similar pattern

Playwright's automation of browser actions is like robotic process automation in industry, showing how software can mimic human tasks reliably.

Common Pitfalls

#1 Running tests without isolating state causes flaky failures.

Wrong approach:

test('test1', async ({ page }) => {
await page.goto('/dashboard');
// assumes user is logged in from previous test
await expect(page.locator('text=Welcome')).toBeVisible();
});

test('test2', async ({ page }) => {
await page.goto('/dashboard');
await expect(page.locator('text=Welcome')).toBeVisible();
});

Correct approach:

test.use({ storageState: 'auth.json' });

// Save login state once
// Then reuse in tests

// test1 and test2 both load storageState to ensure login

Root cause:

Misunderstanding that each test runs in a fresh browser context and needs explicit login or saved state.

#2 Using brittle selectors that break on UI changes.

Wrong approach:

await page.click('button.submit'); // class names can change

Correct approach:

await page.click('[data-testid="submit-button"]'); // stable test id selector

Root cause:

Not using stable, purpose-built selectors leads to fragile tests that break with minor UI updates.

#3 Ignoring async waits causing tests to fail intermittently.

Wrong approach:

await page.click('button');
await expect(page.locator('text=Done')).toBeVisible(); // no wait for navigation or response

Correct approach:

await Promise.all([
page.waitForNavigation(),
page.click('button'),
]);
await expect(page.locator('text=Done')).toBeVisible();

Root cause:

Not waiting for page events or responses causes tests to check too early before UI updates.

Key Takeaways

E2E testing with Playwright simulates real user actions to verify the entire app works as expected.

Playwright supports multiple browsers and runs tests in parallel for fast, reliable cross-browser testing.

Proper test setup, including authentication state reuse and stable selectors, is key to maintainable tests.

Debugging tools like headed mode and reports help quickly find and fix test failures.

Advanced test architecture with isolation and parallelism ensures scalable and trustworthy test suites in production.