What Playwright is, and where it fits

Playwright is a tool that opens a web browser and performs the same actions a person would: clicking buttons, typing into forms, and reading what appears on the screen.

The difference is that it does this in a few seconds, and it does exactly the same thing every time.

Here is the problem it solves.

Say your site has a login page. You check it by hand. The correct password works. The wrong password shows an error. It works, so you move on.

Two weeks later, someone edits a piece of code that the login page shares with another screen. Login quietly breaks. Nobody checks it, because login already worked. A customer finds it on Monday morning.

Instead of repeating these checks by hand after every change, Playwright lets you describe them in code. The check is written once, and runs automatically from then on.

What a test looks like

test('shows an error when the password is wrong', async ({ page }) => {
  await page.goto('/login');
  await page.getByLabel('Email').fill('demo@example.com');
  await page.getByLabel('Password').fill('wrong-password');
  await page.getByRole('button', { name: 'Sign in' }).click();
  await expect(page.getByTestId('error')).toHaveText('Incorrect password');
});

Read it from top to bottom. It is close to English.

• test(...) is one test. The sentence inside is what you say the app should do.
• page is the browser tab your test controls.
• page.goto opens a page.
• getByLabel and getByRole point at an element, meaning one thing on the page such as a button or a text box. They describe it the way a person would: the box labelled Email, the button named Sign in. Lecture 5 covers this properly.
• .fill and .click do what a user does.
• expect(...) is the check.

Every line starts with await. That is because each action takes a moment to happen in a real browser, and await means "wait for this to finish before the next line". Lecture 8 explains what is going on underneath.

That last line is the important one. Without it, the test clicks through the page and proves nothing.

A test is steps plus a check. The steps make something happen. The check decides whether it was right.

Where Playwright fits

Playwright interacts with your application through a browser, performing the same types of actions users perform: clicking, typing, and checking results.

This is called end-to-end testing, because it checks a complete user journey through your application, from the user's actions in the browser to the expected result.

Other kinds of tests exist. A unit test checks one function on its own, with no browser. Unit tests are faster and narrower. End-to-end tests are slower and closer to real life, so teams write a small number of them, covering the journeys that matter most, like signing in and paying.

Playwright also handles many timing problems automatically, so you will not need to add manual pauses to your tests. Lecture 9 covers how that works.

Playwright is one of three tools you will see in job postings for this work. The others are Cypress and Selenium. They solve the same problem in different ways, and this site teaches all three.

One honest thing before you start

An automated test does not find new bugs. It cannot look at a screen and decide that the wording is confusing.

What it does is notice when something that used to work stops working. That is most of the value, and it is why a test written in March still earns its place in September.

Remember this: Playwright drives a real browser through your app, and the check at the end is what makes it a test.

Next: the apps you will practise on.

Reference: Playwright documentation