Practice Fundamentals Overview
Start here
Start here - Playwright fundamentals

Playwright overview: what it is, and how a test becomes a browser result

Before the first locator, one page on what you are actually driving. What Playwright is, the six stages a test goes through from npx playwright test to the HTML report, and the connection underneath: the driver, the protocols, and where the WebSocket sits. Walk the architecture step by step below, then go to the curriculum hub.

6Stages per test run
3Engines, one API
1Browser per worker
Hub ->Next: curriculum

1What Playwright is

An open source browser automation library and test runner from Microsoft. One API drives three engines, and it ships its own driver, so there is no WebDriver and no separate server to install.

@playwright/test Chromium Firefox WebKit auto-wait web-first expect fixtures trace viewer
  • Library plus runner. playwright-core drives the browser. @playwright/test adds the runner: projects, workers, fixtures, retries, tracing and the HTML report. In this curriculum you use both.
  • Three engines, one script. Chromium, Firefox and WebKit. Playwright ships and patches its own builds, so the same test runs on all three without changing a line.
  • Actionability built in. click() waits until the element is visible, stable, enabled and receives events. expect() retries until the assertion passes or the timeout runs out.
  • Official bindings. TypeScript and JavaScript, Python, Java and .NET. The Node.js driver underneath is the same for all of them, which is the subject of section 3.
In one sentence: your test sends commands to a driver, the driver speaks the browser's own protocol, and events flow back the same way until the report is written.

2The architecture, step by step

Press Play, or click any panel. Each stage highlights on the map and shows the command or code that belongs to it.

Step 1 / 6
YOUR MACHINE, ONE TEST RUN 1 Write and run npm init playwright@latest tests/example.spec.ts npx playwright test 2 Runner and worker playwright.config.ts runner schedules workers each worker starts a browser 3 Browser, context, page Chromium / Firefox / WebKit context = isolated session page = one tab 4 Navigate and act page.goto(url) click, fill, press actions auto-wait 5 Check the result expect(page).toHaveTitle() retries for up to 5000 ms web-first assertions 6 View the report pass or fail per test npx playwright show-report traces and screenshots
Keyboard: left and right arrows move between steps while the player has focus.

3How the test talks to the browser

The part every architecture diagram draws and few explain. Your code never touches the browser directly. It talks to the Playwright driver, and the driver talks to each engine in that engine's own language.

Playwright architecture poster: client libraries in TypeScript or JavaScript, Python, Java and .NET send JSON-RPC messages over one open WebSocket to the Playwright driver, a Node.js server, which drives Chromium over CDP and Firefox and WebKit over Playwright's own protocol. Two panels below explain that a local run uses a pipe rather than a socket and which protocol each engine speaks, and a strip lists three facts: bidirectional, one persistent connection, one driver for every language
The short version on one poster: your test, one open channel to the Node.js driver, and three engines that each speak their own protocol. The channel is a WebSocket only when the driver runs somewhere else (a Docker grid, a cloud farm, a run-server); on your own machine it is a pipe. The map below is the precise version.
Your test, client libraryTypeScript / JavaScriptPython, Java, .NETcalls page.goto(), click() JSON-RPC commands down,events and results back pipe locally, WebSocket remotely Playwright drivera Node.js processspeaks every engine's protocolone driver, three engines CDP PW protocol PW protocol Chromiumalso Chrome, Edge via channel Firefoxa build Playwright patches WebKitSafari's engine, on any OS
  • Bidirectional and persistent. The channel opens once per session and stays open. Commands go down (goto, click, fill); responses and events come back (page loaded, console message, network request, dialog opened). That is why Playwright can react to the page instead of polling it.
  • Pipe locally, WebSocket remotely. In a TypeScript or JavaScript project the client and the driver live in the same Node.js process, and the driver launches Chromium with --remote-debugging-pipe. The WebSocket appears the moment the driver is somewhere else: browserType.launchServer() exposes a wsEndpoint(), browserType.connect(wsEndpoint) attaches to it, npx playwright run-server runs a standalone driver, and connectOverCDP() attaches to a Chromium that is already running. Docker grids and cloud device farms use this path.
  • CDP is Chromium only. The Chrome DevTools Protocol is the same channel DevTools itself uses, which is why Chrome, Edge and Brave all work through channel or executablePath. Firefox and WebKit have no CDP; Playwright drives them with its own protocol over builds it patches and ships. Some diagrams label that "CDP+". Read the plus as "not CDP".
Deep dive: the architecture blueprint plays the same journey node by node, from the test file through dispatcher, auto-wait engine, protocol layer and renderer, with an interactive player per locator command.

4Browser, context, page: what is shared and what is fresh

The one sentence from the diagram that decides how your tests behave, and the one interviewers ask about.

ObjectWhat it isAcross two tests in one worker
browserOne engine instance per configured projectSame object, reused
contextAn isolated session: cookies, storage, permissions, viewportNew object every test
pageOne tab inside that contextNew object every test

That table is not quoted from documentation. It was measured: two tests in a serial block captured their fixtures, and the second test asserted expect(seen[0].browser).toBe(seen[1].browser) and expect(seen[0].context).not.toBe(seen[1].context). Both passed on Playwright 1.62 with Chromium 151.

  • Why the browser is reused: launching an engine costs seconds; a context costs milliseconds. One browser per worker gives you isolation without paying the launch price on every test.
  • Why the context is fresh: nothing leaks between tests. A login in test one is gone in test two unless you save and reuse storage state on purpose.
  • More workers, more browsers. Each worker process starts its own browser, which is what parallel execution means here.

5Where to go next

Curriculum hub: the six modules Architecture deep dive First practice page: element filter
Reading order. This page, then the hub's module 1 (setup and first test), then the architecture blueprint once the six stages above feel familiar. The blueprint assumes you already know what a worker and a context are.