Playwright Tutorial for Beginners

Last reviewed November 2026 against @playwright/test 1.65.0.

Playwright is an open-source browser automation library and test runner maintained by Microsoft. You write a test once, and the same code drives Chromium, Firefox and WebKit (the engine behind Safari). This course teaches it the way most teams actually use it today: TypeScript, the @playwright/test runner, and a suite that ends up running in CI and on a cloud browser grid.

If you have written Selenium or Cypress tests before, three design decisions explain most of what will feel different.

1. Actions and assertions wait for you#

In Playwright you do not sprinkle sleeps or explicit waits around your clicks. Before click() runs, Playwright checks that the element is visible, stable (not animating), enabled, not inert, and actually receives the click (no overlay sitting on top of it). If those checks do not pass in time, the action fails with a TimeoutError that tells you which check was not met.

Assertions work the same way. This line keeps re-checking the page until the heading appears or the assertion timeout (5 seconds by default) runs out:

await expect(page.getByRole('heading', { name: 'Installation' })).toBeVisible();

That combination, auto-waiting actions plus retrying "web-first" assertions, is the main reason Playwright suites tend to be less flaky than suites built on fixed waits. Chapter 3 covers it in depth, including the habits that quietly undo it.

2. Every test gets a fresh browser context#

A browser context is an isolated, incognito-like profile: its own cookies, local storage and cache. Creating one takes milliseconds, so the test runner gives every test a brand-new context while reusing the browser process underneath. Tests cannot leak a logged-in session or a cart into each other, and you get that isolation without paying for a browser launch per test.

The same mechanism powers authentication reuse: log in once, save the context's storage state to a file, and start every later test already signed in (chapter 4).

3. One API, three engines#

page.getByRole('button', { name: 'Save' }).click() is the same call whether the project is configured for Chromium, Firefox or WebKit. Cross-browser coverage is a list of projects in playwright.config.ts, not three code paths:

projects: [
  { name: 'chromium', use: { ...devices['Desktop Chrome'] } },
  { name: 'firefox',  use: { ...devices['Desktop Firefox'] } },
  { name: 'webkit',   use: { ...devices['Desktop Safari'] } },
],

One caveat worth knowing early: Playwright's WebKit is built from upstream WebKit sources, often ahead of what Apple has shipped in Safari, so it is a strong signal for Safari but not the browser your users have installed. Your laptop also covers only one operating system. Both are reasons chapter 8 runs the same suite on remote Windows and macOS machines.

Playwright in other languages#

Playwright also ships official bindings for Python, Java and .NET. The concepts in this course (locators, auto-waiting, contexts, tracing) carry over directly; in Python, for example, page.get_by_role("button", name="Save") is the same locator with snake_case names, usually run through the pytest-playwright plugin. The test runner features covered here (projects, fixtures, sharding, the HTML reporter) are specific to the Node.js @playwright/test package, which is why the course uses TypeScript throughout.

If you are still choosing a framework, our Playwright vs Selenium comparison and Cypress vs Playwright comparison walk through the trade-offs.

How the course is organised#

Each chapter builds on the same small project, so by the end you have one suite that you understand line by line:

1. Install Playwright and run a first test
2. Locators: finding elements the way users do
3. Auto-waiting and web-first assertions
4. Fixtures, hooks and logging in once
5. Debugging with UI mode, the trace viewer and codegen
6. Multiple browsers, workers and sharding
7. Running the suite in GitHub Actions
8. Running the same suite on a cloud browser grid
9. A knowledge check

The examples run against two public demo sites so you can copy them and see them pass: Playwright's own TodoMVC demo at demo.playwright.dev/todomvc, and a login form at the-internet.herokuapp.com. Swap in your own application whenever you are ready.

A note on the word "certification", since people search for it: Microsoft does not offer an official Playwright certification. The course itself is free and needs no account; the knowledge check at the end is a self-check. If you want something to show an employer, the optional TestingBot certification asks for two things: a passed exam and this course's suite running green on TestingBot. It is issued by TestingBot, not by Microsoft or the Playwright project, and the certificate says so.

What you'll build#

A TypeScript Playwright project that:

• tests a todo app with role-based locators and retrying assertions,
• logs in once in a setup project and reuses the session in every test,
• runs on Chromium, Firefox and WebKit in parallel,
• runs on every push in GitHub Actions and uploads the HTML report and traces,
• runs unchanged against remote browsers on Windows and macOS through a WebSocket endpoint.

Prerequisites#

• Node.js 22, 24 or 26 (the latest release of one of those lines; Playwright no longer tests on Node.js 20).
• Comfort with basic JavaScript or TypeScript, including async/await.
• A terminal and a code editor. VS Code with the official Playwright extension is convenient, but not required.
• Git and a GitHub account for chapter 7, and a TestingBot account for chapter 8 (the free trial is enough).