1. Functional understanding comes first

My first step is always on the functional side. I read the user story fully and check if all acceptance criteria make sense. If anything is unclear or has gaps, I talk to the developer or product owner and clarify it.
It's better to clear doubts early instead of assuming something and later rewriting automation.

2. Write manual test cases

Once the functionality is clear, I write manual test cases covering all possible scenarios:

• happy paths

• edge cases

• negative cases

• functional and UI validations

This gives me confidence that I have covered the story from all angles.

3. Manual execution before automation

Next, I execute these manual test cases on the application.

• If I find bugs, I log them and wait for fixes.

• If everything works fine, then I move towards automation.

This avoids writing automation for a broken feature.

4. If there is a blocker, still make partial progress

Sometimes the story is half-working or blocked. In those cases, I don’t sit idle. I do whatever is possible:

• open all reachable screens

• capture locators

• design the page objects

• plan which class should hold which method

• create placeholder/dummy methods without implementations

This saves time later because the structure is already ready.

5. When the story is stable, start automation

Once the feature is stable, automation becomes straightforward. I start implementing the test using the existing framework conventions and project structure.

6. Use codegen for a quick head start

I run the same scenarios using Playwright codegen. Codegen gives raw steps which are not production-ready, but it helps me quickly get all actions and locators.

I then pass this generated script to AI tools and ask them to rewrite it following:

• Page Object Model

• DRY (Don’t Repeat Yourself)

• proper naming

• reusable functions

This gives a good starting structure. I only use AI as an assistant, not as a final answer.

7. Keep an .md guide in the repository

Maintaining a .md file with good examples of:

• page structure

• locator strategy

• fixtures usage

• naming conventions
  is very helpful.
  Anyone new in the team can learn faster, and even I can reuse patterns easily.

8. Replace weak locators manually

AI or codegen cannot always give good locators. They usually pick long CSS or nth-child types, which are flaky.
So I manually rewrite locators using:

• getByRole

• getByTestId

• stable attributes

This improves long‑term stability.

9. Write meaningful assertions

Codegen cannot create strong assertions. It only does basic checks like:

• element visible

• text present

But real automation needs:

• data validation

• API + UI comparison

• sorting logic

• complex workflows

These I write manually based on business rules.

Final thoughts

AI is helpful, but it cannot understand the product like a human tester. It can speed up repetitive parts, but functional thinking and assertion design still need human effort.
This is the simple and practical process I follow for automating one story in a stable and clean way.

Sometimes when you're testing a website, things don't go as planned. You might be filling out a form or clicking a button, and suddenly — boom — a popup appears out of nowhere. It could be a newsletter signup, a discount offer when you're about to leave the page, a survey, or even a live chat window asking if you need help. These overlays can block the main content and interrupt your test flow.

The tricky part? These popups don’t always show up. Sometimes they appear, sometimes they don’t. That makes it hard to write stable tests because you can’t predict when they’ll show up.

That’s where Playwright’s special function comes in — addLocatorHandler.

This function lets you set up a handler that watches for a specific popup or overlay. If it appears, the handler kicks in and takes care of it (like clicking the close button), so your test can continue without getting stuck.

In this blog, I’ll show you how to use this feature to handle those unexpected overlays and keep your tests running smoothly.

Demo:

let me show you a demo. I have created a very simple site, and which might show subscribe newsletter popup 60% of the time.

To launch a site locally, follow these steps:

1. save this file with .html extension

<!DOCTYPE html>
<html lang="en">
  <head>
    <meta charset="UTF-8" />
    <title>Newsletter Popup Demo</title>
    <style>
      body {
        font-family: Arial, sans-serif;
        margin: 0;
        padding: 0;
        overflow: auto;
      }

      .overlay {
        display: none;
        position: fixed;
        top: 0;
        left: 0;
        width: 100vw;
        height: 100vh;
        background-color: rgba(0, 0, 0, 0.6);
        z-index: 1000;
        justify-content: center;
        align-items: center;
      }

      .modal {
        background: white;
        padding: 30px;
        border-radius: 10px;
        width: 300px;
        text-align: center;
        box-shadow: 0 0 15px rgba(0, 0, 0, 0.3);
        position: relative;
      }

      .modal input[type="email"] {
        width: 90%;
        padding: 10px;
        margin: 10px 0;
      }

      .modal button {
        padding: 10px 20px;
        margin-top: 10px;
      }

      .close-btn {
        position: absolute;
        top: 10px;
        right: 15px;
        font-size: 20px;
        font-weight: bold;
        color: #999;
        cursor: pointer;
      }

      .close-btn:hover {
        color: #333;
      }

      .content {
        padding: 20px;
      }

      .hidden {
        display: none;
      }
    </style>
  </head>
  <body>
    <div class="overlay" id="newsletterOverlay">
      <div class="modal">
        <span class="close-btn" onclick="closeOverlay()">×</span>
        <h2>Subscribe to our Newsletter</h2>
        <p>Get the latest updates and offers!</p>
        <input type="email" placeholder="Enter your email" />
        <br />
        <button onclick="subscribe()">Subscribe</button>
      </div>
    </div>

    <div class="content" id="mainContent">
      <h1>Welcome to Our Awesome Site!</h1>
      <p>Enjoy browsing our content. You might get a surprise!</p>

      <div><label>Your name:</label><input type="text" id="name" /></div>
      <br />
      <div><label>Your age:</label><input type="number" id="age" /></div>
      <br />
      <div>
        <label>Your profession:</label><input type="text" id="profession" />
      </div>
      <br />
      <div><label>Your city:</label><input type="text" id="city" /></div>
      <br />
      <div><label>Your state:</label><input type="text" id="state" /></div>
      <br />
      <div><label>Your country:</label><input type="text" id="country" /></div>
      <br />
      <div>
        <label>Your continent:</label><input type="text" id="continent" />
      </div>
      <br />
    </div>

    <script>
      function showOverlay() {
        const shouldShow = Math.random() < 0.5; // 50% chance
        if (shouldShow) {
          document.getElementById("newsletterOverlay").style.display = "flex";
          document.getElementById("mainContent").classList.add("hidden");
          document.body.style.overflow = "hidden";
        }
      }

      function closeOverlay() {
        document.getElementById("newsletterOverlay").style.display = "none";
        showForm();
      }

      function subscribe() {
        alert("Thanks for subscribing!");
        closeOverlay();
      }

      function showForm() {
        document.getElementById("mainContent").classList.remove("hidden");
        document.body.style.overflow = "auto";
      }

      window.onload = function () {
        showForm(); // Show form initially
        setTimeout(showOverlay, 2000); // Show popup after 2 seconds
      };
    </script>
  </body>
</html>

2. run the .html file with live server in vscode

3. Copy the url. Same should be used inside the page.goto() method

Playwright code:

Logic is simple

Some popups might appear (the popup locator is provided to Playwright). If this locator appears, then do the following:

We have set up a handler to detect if the given locator appears on the screen using the addLocatorHandler function. then do this action mentioned in the async function

Then it fills data in each textbox, and I have set a 1-second timeout for each fill. This allows time for the newsletter popup to appear; otherwise, the automation might finish before the popup shows up.

import { test } from "@playwright/test";

test("custom site with overlay handler", async ({ page }) => {
  // Register a handler to close the newsletter popup if it appears
  await page.addLocatorHandler(
    page.getByText("Subscribe to our Newsletter"),
    async () => {
      await page.locator("span.close-btn").click();
    }
  );

  // Proceed with the test
  await page.goto("http://127.0.0.1:5501/over.html"); 
  // you have to change this url. steps are available in below
  await page.locator("#name").fill("Your Name");
  await page.waitForTimeout(1000); 
  //given timeout otherwise test will be completed before the overlay appears
  await page.locator("#age").fill("30");
  await page.waitForTimeout(1000);
  await page.locator("#profession").fill("Software Engineer");
  await page.waitForTimeout(1000);
  await page.locator("#city").fill("Bangalore");
  await page.waitForTimeout(1000);
  await page.locator("#state").fill("Karnataka");
  await page.waitForTimeout(1000);
  await page.locator("#country").fill("India");
  await page.waitForTimeout(1000);
  await page.locator("#continent").fill("Asia");
});

Conclusion:

Dealing with unexpected popups during test automation can be frustrating, especially when they don’t always show up. But with Playwright’s addLocatorHandler, we now have a clean way to handle these overlays without breaking our tests. It helps us keep our scripts smooth and focused on the actual task, even when something tries to interrupt. Try it out in your tests and get rid of all flaky tests.

Here is the scenario:

A report is expected to come from some source, and it takes time to receive.

Since this step which is verifying the report file’s presence is a synchronous one and it is not going to retry and fail in first attempt itself

import {test,expect} from "@playwright/test";
import { existsSync } from 'fs';

test('file presence check', () => {
  const exists = existsSync('downloads/report.pdf'); 
  // as per scenario , file is going to arrive late at this destination
  expect(exists).toBeTruthy();
});

Bad solution:

waiting for 1 minutes by default.

import {test,expect,page} from "@playwright/test";
import { existsSync } from 'fs';

test('file presence check',async ({page}) => {
  // as per scenario , file is going to arrive late at this destination
  await page.waitForTimeout(1*60*1000);
 const exists = existsSync('downloads/report.pdf'); 
  expect(exists).toBeTruthy();
});

1. If file arrives early, still test will wait for 1 minutes.

2. Using complex for loops or while loops

   unnecessary code complexity

ToPass() assertion

This assertion is going to retry executing a block of code until all the assertions inside the block is passed.

import {test,expect,page} from "@playwright/test";
import { existsSync } from 'fs';

test('file presence check', async () => {
  await expect(() => {
    const exists = existsSync('downloads/report.pdf');
    expect(exists).toBeTruthy();
//here i have only one assertion
  }).toPass();
});

Why it is better:

1. Assertion is going to pass and move to next steps for execution so timing is saved

2. No complex looping code is required.

Poll() assertion

It is similar to the Pass() but here it works on single assertion. it returns a value, and assertion is done on it.

Scenario:

let’s assume you have a field and it is value is changing and you want to check if it is greater than 5

import {test,expect,page} from "@playwright/test";

test('Number validateion', async () => {
  const count = await page.locator('.notification-badge').textContent();
  const countInNumber = parseInt(count || '0');
  expect(countInNumber).toBeGreaterThan(5);
});

Here also it is not wise to use the waitforTimeout for any other loops for the same reason we discussed before

The better solution would be

import {test,expect,page} from "@playwright/test";

test('Number validateion', async () => {
  await expect.poll(async () => {
      const count = await page.locator('.notification-badge').textContent();
      return parseInt(count || '0');
  }).toBeGreaterThan(5);
});

Understanding the difference

This 2 may seem almost close with no difference but based on my experience this is what i have understood as the differences between this 2.

Thanks for reading my blog and hope you have learnt something new here.

please subscribe to my newsletter for more.

Just imagine how you will access a particular website.

1. You will open a browser . This does the below tasks in the background

   1. Opens up your profile (so cookies, logged in sessions can be reused)

      

   2. Creates a new tab automatically

      

2. you will hit the url in the url textbox

   1. 

just like above, we can do the things manually in the playwright code but why not preferred

test.only("validate orange hrm portal", async ({}) => {
  const browser = await chromium.launch({ headless: false });
  const context = await browser.newContext();
  const page = await context.newPage();
})

1. Playwright creates browser and context behind the scenes because all tests need the page for sure, code redundancy is removed with this.

2. This will overwrite the project configuration from playwright.config.json file and will execute in that browser mentioned in the test only . here it will be chromium. you have to make code change to run it in firefox, webkit

import { test, expect } from "@playwright/test";

test.only("validate orange hrm portal", async ({ page }) => {
  await page.goto(
    "https://opensource-demo.orangehrmlive.com/web/index.php/dashboard/index"
  );
});

Playwright decides which browser to open based on the playwright.config.json file

Now let’s explore the Browser, context, page with examples

1. Browser

This below code creates a browser but if you run this, you won’t see anything on the screen. because playwright is super-fast

import { test, chromium, firefox, webkit } from "@playwright/test";
test.only("validate orange hrm portal", async ({}) => {
 const browser = await chromium.launch({ headless: false });
 const fireFox = await firefox.launch({ headless: false });
 const Safari = await webkit.launch({ headless: false });
})

2. Context

This creates profile so each tests run in a new profile hence so isolated. But again this code won’t show anything on the screen

test.only("validate orange hrm portal", async ({}) => {
  const browser = await chromium.launch({ headless: false });
  const context = await browser.newContext();
})

3. Page

Now when you create a page which is equal to a tab then it will show something on the UI

test.only("validate orange hrm portal", async ({}) => {
  const browser = await chromium.launch({ headless: false });
  const context = await browser.newContext();
  await context.newPage();
})

But that also will be closed very quickly.

Run this to see the 3 browsers open

import { test, chromium, firefox, webkit } from "@playwright/test";

test.only("validate orange hrm portal", async ({}) => {
  const chrome = await chromium.launch({ headless: false });
  const fireFox = await firefox.launch({ headless: false });
  const Safari = await webkit.launch({ headless: false });

  const chromeCntext= await chrome.newContext();
  const fireCntext= await fireFox.newContext();
  const safariCntext= await Safari.newContext();

  await chromeCntext.newPage();
  await fireCntext.newPage();
  await safariCntext.newPage();

});

Now comes the fun part, let’s see it visually the execution.

Scenario1: playing with multiple page (tab)

import { test, chromium, expect } from "@playwright/test";

test.only("validate orange hrm portal", async ({}) => {
  const browser = await chromium.launch({ headless: false });
  const context = await browser.newContext();
  const page = await context.newPage(); //creating first page

  await page.goto(
    "https://opensource-demo.orangehrmlive.com/web/index.php/auth/login"
  );
  await page.getByPlaceholder("Username").fill("Admin");
  await page.getByPlaceholder("Password").fill("admin123");
  await page.getByRole("button", { name: "Login" }).click();
  await expect(
    page.getByText("Employee Distribution by Sub Unit")
  ).toBeVisible();

 const page2 = await context.newPage(); //creating second page using same context
 await page2.goto(
    "https://opensource-demo.orangehrmlive.com/web/index.php/auth/login"
  );
 await expect(
    page2.getByText("Employee Distribution by Sub Unit")
  ).toBeVisible();

});

Code explanation

1. Have hit the HRM site

2. Logged in the site in the first page

3. Created a second page (Tab)

4. hitting the logged in URL in second page

   1. It got logged in already rather than asking me to login.

   2. Because the sessions are shared between tabs

Output:

you see there are 2 tabs, the home page is visible in both the screens rather than login screen

Scenario2: playing with multiple context (profile) and page (tab)

import { test, chromium, expect } from "@playwright/test";

test.only("validate orange hrm portal", async ({}) => {
  const browser = await chromium.launch({ headless: false });
  const context = await browser.newContext();
  const page = await context.newPage();
  await page.goto(
    "https://opensource-demo.orangehrmlive.com/web/index.php/auth/login"
  );
  await page.getByPlaceholder("Username").fill("Admin");
  await page.getByPlaceholder("Password").fill("admin123");
  await page.getByRole("button", { name: "Login" }).click();
  await expect(
    page.getByText("Employee Distribution by Sub Unit")
  ).toBeVisible();
 const context2 = await browser.newContext(); //creating 2nd context here
  const page2 = await context2.newPage(); //creating 2nd page using 2nd context
 await page2.goto(
    "https://opensource-demo.orangehrmlive.com/web/index.php/auth/login"
  );
 await expect(
    page2.getByText("Employee Distribution by Sub Unit")
  ).toBeVisible();
});

Code explanation

1. Have hit the HRM site

2. Logged in the site in the first page

3. Created new context (context2) which is like new profile or incognito session

4. Created a second page (Tab) using the second context

5. hitting the logged in URL in second page

   1. It is asking me to login.

   2. Because the sessions are not shared between tabs

Output:

you see there are 2 browser contexts opened, the home page is visible in the first page but the second page is on the login screen

Youtube link with demo

1. What is locator.click()?

In Playwright, locator.click() is a high-level API used to simulate a mouse click on a web element. It’s part of the Locator API, which provides a robust way to interact with elements on the page.

await page.getByRole('button').click();

This command does the following:

• 1.1 Finds the element matching the selector.

• 1.2 Auto-Waiting Mechanism

  Playwright automatically waits for the element to be:

  • Attached to the DOM

  • Visible (not hidden via CSS or layout)

  • Enabled (not disabled)

  • Stable (not animating or moving)

  • This avoids flaky tests caused by premature clicks.

• 1.3 Scrolls it into view if needed.

  • If the element is outside the viewport, Playwright scrolls it into view using element.scrollIntoViewIfNeeded().

  • This mimics how a real user would interact with off-screen elements.

• 1.4 Performs a click action.

  • When you use the click() method , it does the following actions in sequence to mimic a real user clicking experience.

    • mousedown —> Like when the mouse is pressed, the button goes down

    • mouseup —> Like when the mouse is stopped pressing, the button comes up

    • click —> click is needed though the down and up is triggered otherwise the click won’t be triggered

2. Options You Can Pass to the click function

await page.locator('button').click({
  position: { x: 10, y: 5 }, // click at specific offset
  button: 'right', // 'left' | 'middle' | 'right'
  clickCount: 2,   // for double-click
  delay: 100,      // ms between mousedown and mouseup
  force: true,     // bypass checks
  modifiers: ['Alt', 'Shift'], // keyboard modifiers
  noWaitAfter: true// doesnt wait for navigation if click opens new page/elements
  timeout: 5000,   // override default timeout
  trial: true
});

2.1 position

Playwright calculates the clickable point:

• It finds the center of the visible bounding box.

• If position is specified, it uses that offset.

• It ensures the point is not obscured by another element.

await locator.click({ position: { x: 10, y: 5 } });

2.2 Right click/Left click / Middle click

When right click is needed on a element, this will do the trick.

await page.locator('canvas').click({ button: 'right' }); // Right-click

await page.locator('canvas').click({ button: 'middle' }); // Middle-click

2.3 Double click or more

Sometimes double click will trigger an event, this option can be used in that scenario.

await page.locator('text="Open File"').click({ clickCount: 2 });

2.4 Delay

it's used to introduce a pause between the mousedown and mouseup events discussed in 1.4

await page.locator('button').click({ delay: 500 }); // 500ms delay

2.5 force

this option is used to bypass all actionability checks and force the click, even if the element is:

• Not visible

• Not attached to the DOM

• Covered by another element

• Disabled

• Outside the viewport

await page.locator('#hidden-button').click({ force: true });

Sometimes, elements are technically present but:

• Hidden by overlays or modals

• Slightly off-screen

• Temporarily disabled due to animations or transitions

Using force: true allows you to click them anyway.

Be cautious about this - it skips safety checks.

2.6 Shift+click

lets you simulate keyboard modifier keys being held down during the click — like Shift, Ctrl, Alt, or Meta (Cmd on Mac).

await page.locator('.item').click({ modifiers: ['Shift'] }); 
//"Alt" | "Control" | "ControlOrMeta" | "Meta" | "Shift”

2.7 NowaitAfter

This is used to prevent Playwright from waiting for potential page navigations or asynchronous events that might be triggered by the click.

Deprecated and defaults to false

await page.locator('a#delayed-link').click({ noWaitAfter: true });

will default to true in future releases

2.8 timeout

it controls How Long Playwright Waits for actionability checks

If you don’t specify timeout, Playwright uses the default timeout (usually 30 seconds).

When a element takes time to load and you want to extend or limit the timeout different from gloabl timeout then this can be used.

await locator.click({ timeout: 5000 }); // custom timeout

2.9 Trial Click

You can simulate a click without actually clicking using trial: true. This is useful for checking if an element is clickable.

await locator.click({ trial: true });

3. Common Pitfalls

Some common failures and the causes

Playwright throws a detailed error with suggestions and a trace.

Conclusion

page.locator().click() is one of the most powerful and reliable ways to simulate user interaction in Playwright. By understanding its behavior, options, and best practices, you can write stable, maintainable, and robust automation scripts.

In this post, we’ll explore how getByRole works, why it’s better than traditional selectors, and how to use it effectively in your Playwright tests.

🔍 What is getByRole?

getByRole is a query method from the Testing Library family, integrated into Playwright via @playwright/experimental-ct-* packages. It allows you to select elements based on their ARIA roles, which describe the purpose of an element in the UI.

✅ Why Use getByRole?

Here are some compelling reasons to use getByRole:

• Accessibility-first: Encourages semantic HTML and accessible components.

• Resilient to UI changes: Doesn’t break when class names or IDs change.

• Readable: Clearly communicates the intent of the test.

• Built-in filtering: Supports options like name, level, and hidden.

🧪 Basic Usage

Here’s a simple example using Playwright Component Testing with React:

import { test, expect } from '@playwright/experimental-ct-react';
import LoginForm from './LoginForm';

test('should submit login form', async ({ mount }) => {
  const component = await mount(<LoginForm />);

  const usernameInput = component.getByRole('textbox', { name: 'Username' });
  const passwordInput = component.getByRole('textbox', { name: 'Password' });
  const submitButton = component.getByRole('button', { name: 'Login' });

  await usernameInput.fill('gunasekaran');
  await passwordInput.fill('securepassword');
  await submitButton.click();

  await expect(component).toContainText('Welcome, gunasekaran!'

Did you know the name parameter can come from multiple sources, not just visible text?. here are the list of scenarios that name can handle.

1. Visible text

<button>Submit</button>

await page.getByRole('button', { name: 'Submit' }).click();

2. aria-label

<button aria-label="Submit Form"></button>
await page.getByRole('button', { name: 'Submit Form' }).click();

3. aria-labelledby

<label id="lblUser">Username</label>
<input type="text" aria-labelledby="lblUser">

await page.getByRole('textbox', { name: 'Username' }).fill('admin');

4. Alt text for images

<img src="logo.png" alt="Company Logo">
await page.getByRole('img', { name: 'Company Logo' }).click();

"greeting" —> wrong | page.getByRole('heading', { name: 'Welcome User' }) | Dont get confused with name attribute
name attribute ≠ accessible name in Playwright. |

There are html elements that has implicit role so it won’t have the role attribute manually but still can be identified using role

✅ Implicit ARIA Roles in Native HTML Elements

📚 Conclusion

Using getByRole in Playwright helps you write tests that are not only more reliable but also promote better accessibility. It’s a win-win for developers and users alike. Whether you're testing components or full pages, adopting role-based queries will elevate the quality of your test suite.

An event is a signal that something has happened in the system or application — like a user clicking a button, a page loading, or a dialog appearing.

An event represents a specific action or occurrence that you can listen for and respond to in your code.

✅ Here is the list of events supported in the playwright

Let’s pick the event “dialog” for the demo

1. await promise

Before the event occurs on the browser, we have to instruct the playwright to be ready to handle the event

so the sequence is

• store promise by using waitforevent method without await keyword

• you do the action which triggers the popup

• you wait for the stored promise to fulfil (captured in first step)

• you take action on the event.

    // Start waiting for the dialog before triggering it
    const dialogPromise = page.waitForEvent('dialog');
  
    // Trigger the dialog (e.g., clicking a button that opens an alert/confirm/prompt)
    await page.getByText('Trigger Dialog').click();
  
    // Wait for the dialog to appear
    const dialog = await dialogPromise;
  
    // Accept the dialog
    await dialog.accept();
  
    // Dismiss the dialog (uncomment to use instead of accept)
    // await dialog.dismiss();
  

2. Promise.all

• (same as above but no need (await dialogPromise;) statement)

// Start waiting for the dialog and trigger it at the same time
const [dialog] = await Promise.all([
  page.waitForEvent('dialog'),
  page.getByText('Trigger Dialog').click()
]);

// Accept the dialog
await dialog.accept();

// Dismiss the dialog (uncomment to use instead of accept)
// await dialog.dismiss();

3. ✅ page.on('dialog', callback) method

   • Purpose: Listens for all dialog events continuously and performs the actions defined.

   • Usage: Ideal when dialogs can appear multiple times during a test.

    // Set up a listener for dialog events
    page.on('dialog', async dialog => {
      console.log(`Dialog message: ${dialog.message()}`);

      // Accept the dialog
      await dialog.accept();

      // Dismiss the dialog (uncomment to use instead of accept)
      // await dialog.dismiss();
    });

    // Trigger the dialog (e.g., clicking a button that opens an alert/confirm/prompt)
    await page.getByText('Trigger Dialog').click();

4. ✅ page.once('dialog', callback)

   • Purpose: Listens for only the next dialog event & does whatever mentioned in the once block

   • Usage: Cleaner than page.on when you expect just one dialog.

    // Set up a one-time listener for the next dialog event
    page.once('dialog', async dialog => {
      console.log(`Dialog message: ${dialog.message()}`);

      // Accept the dialog
      await dialog.accept();

      // Dismiss the dialog (uncomment to use instead of accept)
      // await dialog.dismiss();
    });

    // Trigger the dialog (e.g., clicking a button that opens an alert/confirm/prompt)
    await page.getByText('Trigger Dialog').click();

Playwright is an open-source automation framework developed by Microsoft, designed for end-to-end testing of modern web applications. Released in January 2020, it has quickly gained popularity due to its cross-browser, cross-platform, and cross-language capabilities.

Key Features

• Cross-Browser Support: Automates Chromium (Chrome, Edge), Firefox, and WebKit (Safari).

• Multi-Language Support: Works with JavaScript, TypeScript, Python, Java, and .NET.

• Headless Mode: Enables fast, GUI-less testing ideal for CI/CD pipelines.

• Automatic Waiting: Waits for elements to be actionable, reducing flaky tests.

• Browser Contexts: Simulates multiple users with isolated sessions.

• Device Emulation: Tests responsive designs across various screen sizes.

• Network Interception: Mocks API responses and simulates network conditions.

• Built-in Debugging Tools: Includes codegen, trace viewer, and inspector.

Architecture

Playwright uses WebSockets for communication with browsers, unlike Selenium’s HTTP-based approach. This allows faster and more reliable interactions. Each test runs in a separate browser context, ensuring full isolation and faster execution.

Advantages Over Other Frameworks

Playwright stands out for its simplicity, speed, and robust API, making it ideal for modern web apps.

Limitations

• No support for native mobile apps.

• Limited language support compared to Selenium.

• No support for legacy browsers like IE11.

Getting Started

To install and run Playwright:

npm init playwright@latest
# or
pip install playwright

Example test in TypeScript:

import { test, expect } from '@playwright/test';

test('has title', async ({ page }) => {
  await page.goto('https://playwright.dev/');
  await expect(page).toHaveTitle(/Playwright/);
});

Best Practices

• Modularize tests for maintainability.

• Use assertions to validate behavior.

• Run tests in parallel to speed up execution.

• Integrate with CI tools like Jenkins or GitHub Actions.