The source code for this chapter is available at https://github.com/PacktPublishing/Hands-On-Automated-Testing-with-Playwright/tree/main/Chapter02.

When you’re writing end-to-end tests with Playwright, the locators you choose can make a big difference: not just to how reliable your tests are, but also to how accessible your app is. Playwright’s getBy* locators are designed to reflect how real users, including those using assistive tech, interact with your site. By leaning on these locators, you’re not only making your tests easier to maintain but you’re also building a more inclusive experience. Let’s dive into why these locators are preferred.

Why getBy* locators beat CSS and XPath

Playwright makes it easier to work with web elements by offering a handy set of locators such as getByRole, getByLabel, getByPlaceholder, and more. These are designed with accessibility in mind and are a modern alternative to the old-school CSS or XPath selectors (we’ll explore these in more detail shortly).

One of the biggest...

While they might not be the most reliable for long-term use, CSS and XPath selectors can be very helpful when dealing with legacy code or third-party components. Sometimes, you just don’t have control over an element’s accessible attributes. If an element doesn’t have ARIA roles, labels, or other accessibility features, locators may not work as expected.

That’s where fallback selectors come in. They can get the job done when HTML is poorly structured or you’re working with external components. Just keep in mind that these selectors often depend on the page’s structure or internal implementation details, which means they can break more easily if the page changes. So, while fallback selectors are useful in certain situations, it’s best to stick with getBy* locators or test IDs (we’ll discuss test IDs in a bit) whenever you can.

CSS selectors...

Playwright has your back with built-in auto-waiting that pauses your test just long enough for things to be ready. But sometimes, you might need a bit more control, and that’s where custom waits come in handy. In this section, we’ll look at how to make your tests more reliable by using Playwright’s smart auto-wait features and adding custom waits when needed.

How Playwright ensures actions happen at the right time

When you’re working with modern web apps, you’ll often run into dynamic elements that show up, disappear, or change depending on what the user does or what’s happening in the background. These changes can make automated testing tricky. If your test tries to interact with something before it’s ready, it might fail or behave inconsistently.

That’s where Playwright’s auto-wait mechanism and a suite of custom wait methods come in: they ensure...

Working with browser dialogs in Playwright (such as alerts, confirmations, and prompts) is surprisingly easy, thanks to its event-driven API. As soon as a dialog appears on the page, Playwright lets you interact with it right away.

In web applications, these dialogs usually pop up when JavaScript functions such as window.alert(), window.confirm(), or window.prompt() are called. These modal windows pause JavaScript execution until the user responds.

Playwright lets you handle these by listening for the 'dialog' event on the page. When a dialog shows up, Playwright emits the event and hands you a dialog object you can use to understand what kind of dialog it is. You can use the following:

• dialog.type() to find out whether it’s an alert, confirm, or prompt
• dialog.message() to read the message shown in the dialog
• dialog.defaultValue() to see the default input text if it’s a prompt

Playwright sees every web page as a tree made up of frames. The main document is the primary or main frame, and any <iframe> elements inside it are treated as child frames. Some websites use iframes or even nested frames to organize content, often for security or to keep things modular. If you want to interact with something inside one of those frames, such as clicking a button or typing in a field, you’ll need to switch your focus to that specific frame so your actions happen in the right place.

Accessing an iframe

An <iframe> element creates an inline frame that loads another HTML document. It operates as a separate browsing context, meaning elements inside an iframe are isolated from the parent page.

To work with elements inside an iframe, start by finding the iframe using frameLocator. Just call page.frameLocator(selector) and pass in the iframe’s CSS selector, ID, or another attribute to target it...

In web development, the Shadow DOM lets you encapsulate parts of the DOM (such as custom components) so their styles and elements don’t accidentally interfere with the rest of the page. This makes it a bit tricky to access or interact with those nested elements using traditional DOM selectors. Let’s take a look at ways to pierce through this boundary and interact with these encapsulated elements.

Locating the host element

This is often the most direct way to access elements within a Shadow DOM. You first locate the host element that has the Shadow DOM. From this root locator, you can then query for elements within it using standard Playwright locators.

Let’s imagine you have a custom web component like this:

<my-widget>
  #shadow-root
    <div class="internal-button">Click me!</div>
    <style>
      .internal-button { color: blue; }
    </style>
</my-widget>

Here...

In this chapter, you’ve explored some of Playwright’s most useful tools for navigating the ever-changing landscape of modern web interfaces. You’ve gotten hands-on with the reliable getBy* locators and learned when it’s best to fall back on traditional selectors.

You also discovered how Playwright’s smart waiting features can help you handle dynamic content smoothly, which makes your tests less prone to flakiness.

On top of that, you learned how to deal with system dialogs, work with iframes, and interact with shadow DOMs, which are key skills for testing today’s complex, component-driven UIs.

As you proceed with building your tests, always remember that the goal is to mimic genuine user interactions while ensuring your code remains resilient in the face of change.

In our next chapter, we will shift focus to browser-agnostic testing, which ensures tests work across Chromium, Firefox, and WebKit.