🌙
☀️ Dark
PART 23

Frontend Testing

Browser automation, Playwright, visual regression.

Intermediate 45 min read

Revision Sheet

  • Unit Test: Fast, isolated. Use Jest/Vitest.
  • Integration Test: Tests DOM and interaction. Use React Testing Library.
  • E2E Test: Real browser. Use Playwright/Cypress.
  • jsdom: Fake DOM in Node.js.
  • MSW: Mock network requests at the service worker level.

Connections

Frontend testing deeply connects with CI/CD pipelines (Volume 18), as tests act as the primary quality gate before deployment. It also relies heavily on understanding the Browser Rendering Pipeline (Volume 12) when writing effective E2E assertions.

PreviousVolume 22 🏠 Curriculum NextVolume 24
🏠 Curriculum NextVolume 2

Mini Project (20-30 min)

▶ View Solution

Build a simple Todo App and write three tests:

  • Unit: Test the reducer or state management logic that adds a todo.
  • Integration (React Testing Library): Test the component by simulating a user typing into the input and clicking "Add".
  • E2E (Playwright): Spin up a browser, navigate to the local dev server, and add a todo via real browser interactions.

Bigger Project (1-2 hours)

Apply all concepts from this volume to build a comprehensive feature.

▶ View Solution
typescript 
// Example project code here

Interview Questions

Easy: What is the difference between a unit test and an E2E test?

A unit test isolates a small piece of code (like a function) and runs in memory. An E2E test boots up a real browser and tests the entire application stack from the UI to the database.

Medium: Why is React Testing Library preferred over Enzyme?

Enzyme allowed testing internal component state and methods, leading to brittle tests that broke during refactoring. React Testing Library forces developers to test the DOM exactly as the user interacts with it.

Hard: How do you handle testing components that rely on window.matchMedia when using jsdom?

Because jsdom does not implement a layout engine, window.matchMedia doesn't exist or work natively. You have to globally mock the implementation in your test setup file before the tests run.

Senior: Your E2E test suite takes 45 minutes to run on CI and frequently fails due to random timeouts. How do you fix this?

First, parallelize/shard the tests across multiple CI workers. Second, analyze the flaky tests: replace hardcoded sleeps with auto-waiting assertions. Finally, mock external third-party services (like analytics or payment gateways) that might be rate-limiting the CI IPs or causing unpredictable delays.