Lesson 1 of 85 min read
Install Playwright and run your first test
One command gives you Playwright, three browsers and a working example test.
Key takeaways
- 1Run npm init playwright@latest in an empty folder and choose TypeScript.
- 2You get playwright.config.ts, a tests/ folder and an example spec.
- 3npx playwright test runs everything; npx playwright show-report opens the HTML report.
What the config controls
playwright.config.ts sets the baseURL, which browsers run (projects), retries, timeouts and whether traces and screenshots are saved on failure. Change it once instead of editing every test.
Go deeper
Expert notes beyond the basics
- 01
Why TypeScript
TypeScript catches typos in method names and wrong argument types before the test even runs. Most Playwright job listings mention TypeScript or JavaScript, so it is the most useful choice.
- 02
Projects run the same tests on many browsers
Each entry in projects is a browser or device. One test file can run on Chromium, Firefox, WebKit and a Pixel phone without changes.
- 03
Workers and parallel execution
Playwright runs test files in parallel across multiple workers by default, each worker starting its own browser instance. The workers setting in the config, or the --workers CLI flag, controls how many run at once. More workers finish a suite faster but use more CPU and memory, and can overload a shared staging environment, so CI pipelines often tune this number separately from a developer's laptop, where fewer workers may run smoother.
- 04
Retries belong in config, not in your head
The retries option in playwright.config.ts tells Playwright to automatically re-run a failing test a set number of times before marking it failed, which is different from fixing flakiness. A sensible pattern is retries: 0 locally so real bugs surface immediately, and retries: 2 in CI so a one-off timing glitch does not block a pipeline, while still investigating any test that needs a retry to pass.
Common mistakes to avoid
- - Installing Playwright globally instead of per project.
- - Forgetting npx playwright install in CI, so browsers are missing.
- - Setting a high retries count to hide genuinely flaky or broken tests instead of fixing them.
- - Running every project (all browsers) on every local run, slowing down everyday development.
Try it yourself
Set the suite to run only on Chromium and WebKit with 1 retry. What do you change?
Write your answer on paper or in a sheet first, then compare.
Interview questions
How to answer like a confident QA engineer
- Q1
Which browsers does Playwright support?
Model answer
Chromium (Chrome, Edge), Firefox and WebKit (Safari engine), all from one API, plus mobile emulation through device profiles.
- Q2
What is baseURL for?
Model answer
It lets tests call page.goto('/login') so the same suite can run against local, staging or production by changing one setting.
- Q3
What does the workers setting control?
Model answer
How many test files Playwright runs at the same time, each in its own browser process. Increasing it speeds up a large suite but increases resource usage and can make shared test environments unstable.
- Q4
Why keep retries different between local and CI runs?
Model answer
Locally you want to see failures immediately so you can fix them. In CI, environment noise like slow networks can cause rare, real timing issues, so a small retry count avoids blocking the pipeline for a one-off blip while real failures still get flagged for investigation.
Knowledge check
+5 points
Which command runs your Playwright tests?