DEV Community: Jaydeep Karale

How to Scroll to an Element in Playwright

Jaydeep Karale — Sat, 09 Mar 2024 20:09:56 +0000

Creating visually stunning and interactive websites has become a norm in the dynamic landscape of web development. However, this has led to the proliferation of content-rich pages extending beyond the viewport’s confines. As a result, users often need to scroll to an element to access all the information available.

Scrolling isn’t just a technical necessity; it’s a critical aspect impacting user experience and site visits. When paired with lazy loading, efficient scrolling enhances engagement, encourages content discovery, and positively affects search engine rankings, leading to longer site visits and a more successful online presence.

In this Playwright tutorial, we’ll learn how to scroll to an element in Playwright. We’ll explore scenarios where scrolling is essential, understand the challenges it addresses, and provide practical insights into implementing effective scrolling strategies. So, let’s dive in and uncover the techniques that ensure your automated tests are as comprehensive and reliable as possible.

The Need to Scroll to an Element

For automation testers, replicating user interactions accurately is crucial to ensure the functionality and performance of these web applications.

This is where the need to scroll to an element arises in automation testing. Automation testers can utilize tools and frameworks to simulate user behavior and interactions on web pages. Scrolling, an essential aspect of user experience, becomes necessary when testing web applications. Scrolling allows testers to interact with hidden, dynamic content or lazy-loaded content, verify content, and validate the responsiveness of a website. It’s about reaching elements beyond the current viewport and ensuring the application behaves seamlessly during user navigation.

In browser automation, Playwright has emerged as a powerful automation testing framework for automating interactions with web pages. In automation testing, mastering the art of scrolling with tools like Playwright becomes pivotal for ensuring web applications’ functionality and performance. With its auto-wait feature for elements to be actionable, cross-browser compatibility, and support for multiple programming languages, Playwright empowers testers to mimic user actions and assess a website’s functionality efficiently.

Discover how to elevate your automation testing using Selenium for robust web applications.

How to Setup Playwright?

Playwright is an open-source, end-to-end testing and browser automation framework released by Microsoft. For this blog on how to scroll to an element in Playwright, we will use the Python API of Playwright.

Step 1: Create a dedicated virtual environment

Creating a dedicated virtual environment is a good practice when working with Python. It helps create an isolation between dependencies for various projects.

For this project, we will create a virtual environment called playwrightscroll using Python 3.10.

conda create -n playwrightscroll python=3.10

The creation of a virtual environment can also be done using the built-in venv module.

python -m venv playwrightscroll

Step 2: Activating the virtual environment and installing Playwright

Next, we activate the newly created virtual environment using the conda.

conda activate playwrightscroll

If not using conda, the command to activate it using the activate script provided within the playwrightscroll virtual environment.

Once activated, the Python API of Playwright can be installed using pip install pytest-playwright.

Step 3: Installing browsers (Required only when running tests locally)

The default Playwright installation does not come with any browser. We need to install the browsers using the playwright install command.

This will install the latest versions of Chromium, Firefox, and Webkit. This step is optional and unnecessary if we use Playwright on cloud testing platforms like LambdaTest.

LambdaTest is an AI-based test orchestration and execution platform that allows you to run Playwright tests on a scalable and reliable cloud grid. With LambdaTest, you can perform Playwright testing on over 3000 unique combinations of browsers, operating systems, and devices.

Catch up on the latest tutorial around the Playwright visual regression testing, automated testing, and more. Subscribe to the LambdaTest YouTube Channel for quick updates.

Learn the secrets of Jenkins for automation testing to streamline your CI/CD pipelines.

This completes the setup required.

Let us do a quick version check so that replicating the setup when referring to this blog will be easy. As shown, the scenarios demonstrated in this blog hereafter are fully compatible with

Python 3.10.12
Playwright 1.37.0
pytest 7.4.0

Scrolling to an Element in Playwright

Vertical scrolling is available on most websites, from those using simple HTML and CSS to Single-Page Applications (SPA) developed using complex modern web technologies like React and Angular and so on.

Horizontal scrolling is considered bad UX and should generally be avoided (or minimized) if necessary. Don’t take my word for it; check out this usability guideline from the world leaders in Research-Based user experience.

There are three ways to scroll to an element in Playwright. Let us briefly understand each of them before moving on to the demo of each method.

Master mobile app automation testing using Appium for flawless mobile apps.

scroll_into_view_if_needed() method

This method is called after locating an element using the Playwright Locator. If the element passes the actionability checks of being Stable and Attached, this method will try to scroll to an element in Playwright.

Usage

locator.scroll_into_view_if_needed(**kwargs)

Arguments

timeout float (optional): Maximum time in milliseconds; default is 3000

Mouse API wheel() method

The mouse class helps simulate the movement of the mouse, with the top left corner of the viewport considered the starting point. Each Playwright page has access to its instance of the mouse class available via page.mouse().

In the mouse class, we can call the page.mouse.wheel() method to scroll to an element in Playwright either in the upward or downward direction.

Usage

mouse.wheel(delta_x, delta_y)

Arguments

delta_x float: Pixels to scroll horizontally

delta_y float: Pixels to scroll vertically

Keyboard API press() method

The keyboard class provides an API for managing a virtual keyboard. Using this API’s press() method and supplying the arguments PageDown, PageUp, ArrowUp, ArrowDown, ArrowLeft, or ArrowRight, we can simulate scrolling in the required direction.

Usage

page.keyboard.press()

Arguments

key str: Name of the key to press or a character to generate, such as ArrowLeft or a.

delay float (optional): Time to wait between keydown and keyup in milliseconds. Defaults to 0.

Now that we know the various methods available to scroll to an element in Playwright, let us study each of them in detail using various scenarios and their implementation, starting with the scroll_into_view_if_needed() method.

Unlock the power of automation testing in Python for more efficient coding and testing.

Demonstration: Using the scroll_into_view_if_needed() Method

In this section, you will learn how to scroll to an element in Playwright using the scroll_into_view_if_needed() method.

The scroll_into_view_if_needed() method brings an element located using a Playwright Locator into the viewport. If the located element is already in the viewport, the method takes no action.

To understand this, let us consider a practical scenario where an element is absent in the viewport.

Test Scenario: Element not visible in the current viewport

Navigate to the LambdaTest Selenium Playground website.
Locate the ‘Contact Us’ element.
Use the scroll_into_view_if_needed() method to scroll down to the ‘Contact Us’ element.
Viewport should be scrolled down and show the ‘Contact Us’ element.

Implementation

The complete test code is as follows.

def test_scroll_into_view_if_needed(page: Page):
    """
    Test verifies if the contact us section is visible and scrolls to it
    """    
    try:
        page.goto('https://www.lambdatest.com/selenium-playground/')
        base_locator = page.get_by_role('link', name="Contact Us")        
        expect(base_locator).to_be_visible()
        page.pause()
        base_locator.scroll_into_view_if_needed()
        page.pause()
        set_test_status(page, 'Passed','Blog exists')        
        page.close()
    except Exception as ex:
        set_test_status(page, 'Failed',str(ex))

Code Walkthrough

Let us now go through the test steps step-by-step.

Step 1

The default viewport of the website is shown below. The ‘Contact Us’ section is not visible.

Scrolling down further reveals the ‘Contact Us’ section.

Step 2

Navigate to the website under test using the goto() method.

Step 3

The “Contact Us” section is a link, so we use the get_by_role() Playwright Locator to locate the element.

The located element is stored in the variable base_locator.

Step 4

We use the Playwright expect() assertion to ensure the element ‘Contact Us’ to_be_visible().

The page.pause() will pause the test execution so that we can view that before calling the scroll_into_view_if_needed() method, the element not in the viewport.

An intermediate screenshot from the execution is shown below.

Enhance your skills in automation testing using Java with our expert insights and tips.

Step 5

On the base_locator, we call the scroll_into_view_if_needed() method to bring the element ‘Contact Us’ into the viewport.

The page.pause() is used again to pause the test execution and ensure the browser does not close until we manually unpause it.

Here is a screenshot of the resumed test execution.

The actionability logs highlighted at the bottom right clearly show the successful scroll.

Step 6

The page.close() closes the session and completes the test.

Execution

The test can be executed using the following command.

pytest -v

Before execution of the scroll_into_view_if_needed() method.

After execution of the scroll_into_view_if_needed() method.

Since we also have the expect() assertion, the test passes as the ‘Contact Us’ element is visible.

Scenario: Element visible in the current viewport

Navigate to the LambdaTest Selenium Playground website.
Locate the ‘Context Menu’ element.
Use the scroll_into_view_if_needed() method on the located Context Menu element.
No efect should be seen on the scroll since the element is already within the viewport.

Implementation

Here is the complete implementation of the test.

def test_scroll_into_view_if_needed_element_already_in_viewport(page: Page):
    """
    Test verifies if the Context Menu section is visible and no scroll happens
    """    
    try:
        page.goto('https://www.lambdatest.com/selenium-playground/')
        base_locator = page.get_by_role('link', name=" Context Menu")
        expect(base_locator).to_be_visible()
        page.pause()
        base_locator.scroll_into_view_if_needed()
        page.pause()
        set_test_status(page, 'Passed','Element exists')        
        page.close()
    except Exception as ex:
        set_test_status(page, 'Failed',str(ex))

Code Walkthrough

The code for this scenario is identical to the scenario we saw before, except for the element that we are locating, which has changed to ‘Context Menu’. Let us do a walkthrough of the same.

Step 1

Navigate to the test website using the page.goto() method.

Step 2

This step changes from scenario #1 we saw above, and we look for the ‘Context Menu’ element, which is already in the viewport.

Step 3

We use the Playwright expect() assertion to make the element ‘Context Menu’ visible. The page.pause() will pause the test execution.

Step 4

On the base_locator, we call the scroll_into_view_if_needed() method. The page.pause() is used again to pause the test execution and ensure the browser does not close.

As we can see, the ‘Context Menu’ is already presented in the viewport. So, the scroll_into_view_if_needed() will be ineffective.

Execution

A single test uses the below command.

pytest -k test_scroll_into_view_if_needed_element_already_in_viewport

As we can see, the element has been located, but scrolling was not required since the ’Context Menu’ element is present in the viewport itself.

Here are the test completion logs from the VS Code terminal.

This marks the completion of the explanation of the scroll_into_view_if_needed() method. The important takeaway for this method is that the scroll to an element in Playwright happens only if the located element is not present within the viewport. If it is already present, the method takes no action.

Let us move on to the second method, which can help perform the scroll action, which is the mouse.wheel().

Demonstration: Using the mouse.wheel() Method

Using the Mouse wheel to scroll to an element in Playwright in either the downward (or upward) direction is the most preferred way users navigate the web page. Playwright provides a mouse class that helps users simulate the actions that can be performed using a mouse.

The mouse class operates relative to the top left corner of the viewport, i.e., the top left of the web page is considered the starting point or the 0,0 position.

While the mouse class API is very comprehensive and lets users perform all the actions allowed by an actual Mouse, the purpose of this blog is limited to exploring the wheel() method.

Test Scenario: Using the mouse.wheel()

Lazy-loading gained prominence with the emergence of the HTML5 specification and the proliferation of mobile devices.

It is a web development technique that aims to improve websites’ performance and user experience by deferring the loading of certain elements, such as images, until they are needed. By implementing lazy-loading, developers can optimize page loading times, reduce bandwidth usage, and enhance a website’s overall speed and responsiveness.

Consider this LambdaTest Demo eCommerce website, which uses a lazy-load tag to improve page load times by loading images outside the viewport only when the user scrolls down to them.

Now that we understand what lazy-loading is and what the benefits are, let us understand how to use the mouse.wheel() method to test websites that employ lazy loading.

Navigate to LambdaTest eCommerce playground.
Locate the ‘Shop By Category’ menu and click it.
Within the ‘Shop By Category’, select the ‘Software’ menu to search for software-related products.
Ensure all product images employing lazy-loading are correctly rendered after scrolling to bring them into the viewport.

Implementation

The complete test code is as below.

def test_scroll_using_mouse_wheel(page: Page):
    page.goto("https://ecommerce-playground.lambdatest.io/")
    page.get_by_role("button", name="Shop by Category").click()
    page.get_by_role("link", name="Software").click()
    page_to_be_scrolled = page.get_by_role("combobox", name="Show:").select_option("https://ecommerce-playground.lambdatest.io/index.php?route=product/category&path=17&limit=75")
    page.goto(page_to_be_scrolled[0])          

    # Since image are lazy-loaded scroll to bottom of page
    # the range is dynamically decided based on the number of items i.e. we take the range from limit
    for i in range(int(page_to_be_scrolled[0].split("=")[-1])):
        page.mouse.wheel(0, 100)
        i += 1
        time.sleep(0.1)

Code Walkthrough

Step 1

We first navigate to the website under test using the page.goto() method.

Step 2

As we can see, the ‘Shop by Category’ element is a button and we use the Playwright Locator get_by_role() and perform the click() action on the located element.

Step 3

The ‘Software’ sub-menu is a link and can be accessed using the get_by_role() locator using the ‘link’ role & name=’Software’.

On the located element, we perform the click() action.

Step 4

The subsequent page that opens by default displays 15 items and is present within a combobox element.

We located the combobox and increased the display option to 75.

Step 5

page_to_be_scrolled[0].split(“=”)[-1] extracts the value 75 from the page URL, and we use this value to decide the vertical distance of the scroll dynamically.

The page.mouse.wheel(0,100) indicates a scroll of 0 pixels horizontally and 100 pixels vertically. We can either increase or decrease this value for faster or slower scrolling.

We do this for 75 iterations based on the total number of objects on the page.

Execution

Let’s execute the single test using the following command.

pytest -k “test_scroll_using_mouse_wheel”

As we can see, the scrolling is seamless and loads the image media as we scroll to an element in Playwright downwards.

Experience seamless testing with our Android device emulator online for perfect app launches.

Demonstration: Using the keyboard.press() Method

The Playwright keyboard class provides an API for managing a virtual keyboard. The high-level API is keyboard.type(), which takes raw characters and generates proper keydown, keypress/input, and keyup events on your page.

We can use the keyboard.down(), keyboard.up(), and keyboard.insert_text() to simulate actions as if they were generated from a real keyboard by a user.

For this blog, we are most interested in the keyboard.press() method that takes keys such as PageDown, PageUp, ArrowUp, ArrowDown, etc, as inputs and performs the relevant action.

Test Scenario: Using the keyboard.press()

Navigate to the Playwright Keyboard API page.
Use the keyboard.press() to scroll in the upward and downward directions on the page.

As can be seen, the keyboard API page has a few sections that extend beyond the current viewport and is a good candidate to test out the ability of the API itself to simulate scrolling.

Implementation

Let us look at the implementation of the code first.

def test_scroll_using_keyboard_press(page: Page):  
    page.goto("https://playwright.dev/python/docs/api/class-keyboard")


    # delay is used to control time between keypress and key release    
    for _ in range(5):
        page.keyboard.press("PageDown", delay=1000)


    for _ in range(5):
        page.keyboard.press("PageUp", delay=1000)


    for _ in range(30):
        page.keyboard.press("ArrowDown", delay=100)

    for _ in range(30):
        page.keyboard.press("ArrowUp", delay=100)

Code Walkthrough

Let us now break down the implementation and understand it step-by-step.

Step 1

We navigate to the Playwright keyboard API page using the page.goto() method.

Step 2

On the page we call the keyboard.press() and perform the ‘PageDown’ action. The delay ensures we do not scroll to an element in Playwright too fast by introducing a 1000ms delay between the PageDown key press and release.

The for loop repeats the PageDown press five times to demo the scrolling.

Step 3

This step is similar to step 1, except we scroll to an element in Playwright in the upward direction using PageUp.

Again, the delay ensures we don’t scroll too fast and can see the scrolling in action.

Step 4

In the next step, we simulate the scroll to an element in Playwright in a downward direction, but this time using the down arrow key ArrowDown and back in the upward direction using ArrowUp.

Execution

Now, let’s execute the single test and check if the scrolling works as expected.

pytest -v “test_scroll_using_keyboard_press”

Implementing Horizontal Scrolling in Playwright

From a usability perspective, horizontal scrolling is generally considered a poor design choice. But there still may be scenarios where horizontal scrolling is necessary; hence, it’s important to test scrolling in the horizontal direction.

To demonstrate how we can achieve horizontal scrolling in Playwright, we will use this demo codepen website, which implements an image gallery.

Test Scenario: Implement Horizontal Scrolling

Navigate to the demo codepen website.
Use the scroll_into_view_if_needed() method to scroll to an element in Playwright in the horizontal direction on the page.

Implementation

The complete test code is as below.

def test_horizontal_scroll(page: Page):
    """
    Test verifies if the contact us section is visible and scrolls to it
    """      
    page.goto('https://codepen.io/ReGGae/full/QZxdVX/')
    for _ in range(50):        
        base_locator = page.frame_locator("#result").locator(f"div:nth-child(3) > article:nth-child({random.choice([1,2,3,4,5])}) > .slide__inner > .slide__img")            
        base_locator.scroll_into_view_if_needed()  
        time.sleep(0.1)        
    page.close()

Code Walkthrough

Let us now break down the implementation and understand it step by step.

Step 1

The demo website renders the image gallery within a < iframe > tag with the name result under a bunch of < article > tags.

We can use the Playwright Codegen tool to obtain the exact locator for the image gallery. It reveals that all the images are nested under div:nth-child(3) and article numbers 1,2,3,4,5.

So, the first image can be located using

div:nth-child(3) > article:nth-child(1) > .slide_inner > .slide_img"

The second image can be located using

div:nth-child(2) > article:nth-child(1) > .slide_inner > .slide_img"

and so on till article:nth-child(5) for the last image

Step 2

We use a Python for loop and combine it with the random.choice() method to randomly locate one of the images within the gallery. Then, we scroll to the located element.

The number 50 in the for loop has been chosen randomly and only serves the purpose of scrolling 50 times. It can be any arbitrary number.

The sleep is added so that we can see the scrolling in action.

Execution

Let’s execute the single test using the following command:

pytest -k “test_horizontal_scrolll”

Are you eager to showcase your skills as a Playwright automation tester? Look no further than LambdaTest’s Playwright 101 certification program! This program is designed for developers who want to demonstrate their expertise in utilizing Playwright to comprehensively test modern web applications.

Conclusion

In conclusion, scrolling stands as a fundamental bridge between users and the wealth of content that modern websites offer. It is not just a navigational tool; it’s a linchpin for user engagement, content accessibility, and, ultimately, a website’s success.

Playwright, a versatile automation tool, equips testers with a powerful arsenal to handle scrolling. Methods like scroll_into_view_if_needed(), mouse.wheel(), and keyboard.press() enables testers to mimic user scrolling actions accurately.

Whether verifying lazy-loading functionality or assessing the rendering of off-screen elements, Playwright empowers testers to conduct comprehensive and reliable automation testing of scrolling, ensuring that web applications perform optimally and deliver exceptional user experiences.

In an era where scrolling plays a pivotal role in user interaction, Playwright is an invaluable ally in the pursuit of flawless web development and testing.

How to Handle iFrames in Playwright

Jaydeep Karale — Mon, 22 Jan 2024 13:14:50 +0000

OVERVIEW

An < iframe > (short for inline frame) is an HTML element that allows you to embed another HTML document within the current page. Introduced in 1998, an iframe is one of the oldest HTML tags. They are commonly used to display external content such as ads, maps, or videos or to create layered user interfaces by loading multiple web pages within a single page.

Modern web development libraries and frameworks like Angular and ReactJS also support iframes. Angular’s built-in security features, such as DomSanitizer, can be used to ensure that content loaded within an iframe is safe and secure.

In addition, to support the native HTML iframe tag, ReactJS also provides a built-in Reactiframe component, which is a wrapper around the HTML tag.

offer several benefits, such as the ability to embed external content like YouTube videos and tweets. Iframes can also be used to isolate content as the JavaScript and CSS of the parent page do not apply to iframe. Another excellent use case for iframes is for displaying advertisements.

With so many use cases for iframes, they are used in websites, and it remains important to be able to test web pages that contain iframes reliably. Not only simple single iframes but web pages that have nested iframes as well.

In this tutorial, we’ll explore how to handle iframes in Playwright, a popular browser automation and end-to-end web testing library. You will learn how to locate an iframe using Playwright locators and how Playwright can handle nested iframes.

In addition to running all the tests to handle iframes in Playwright locally, you will also see how they can be run on a Playwright cloud grid provider.

What is Playwright?

Playwright is an open-source browser automation and end-to-end testing framework released by Microsoft in 2020. Playwright API is available for programming languages such as JavaScript, TypeScript, Python, Java, and .Net.

It also supports all modern browsers, such as Chrome, Firefox, Microsoft Edge, and Safari, making cross browser testing feasible. In addition to being cross-browser, Playwright is cross-platform, which means that tests can be run on Windows, macOS, and Linux either in headless or headed mode.

Calculate SHA1 hashes easily with our SHA1 hash calculator tool

Some key features of Playwright

Playwright provides several key features that set it apart from other automation testing frameworks. Here are some of the key features of Playwright:

Browser Context

Playwright creates a browser context for each test. Browser context is equivalent to a brand-new browser profile. This delivers full test isolation with zero overhead. Creating a new browser context only takes a handful of milliseconds.

Log in once

Playwright helps save the authentication state of the context and reuse it in all the tests. This bypasses repetitive log-in operations in each test yet delivers full isolation of independent tests.

Powerful Tooling

Provides tools such as codegen, which generates tests by recording actions. These tests can be generated in any language. Traceviewer helps capture all test execution information to investigate and debug test failures.

Auto-Wait & Retry

Playwright waits for elements to be actionable before performing actions. It also has a rich set of introspection events. Combining these two eliminates the need for setting artificial timeouts and reduces the flakiness of tests.

All these combined features make Playwright a comprehensive, feature-packed browser automation and end-to-end testing framework.

What are iFrames and how to use them?

Iframes provide a convenient way to embed content from other websites on our website. An iframe can be created using the HTML tag in the body of the page. Let’s see how to embed a YouTube video as an iframe using CodePen.

YouTube provides the code to embed videos into iframe directly.

Head over to the YouTube page of the video you wish to embed into your web page as an iframe and click the Share button.

On the menu that appears, click the “Embed” button.

The code snippet is available to copy & paste into your webpage. Like most websites that allow embedding, YouTube also allows customization of the embedding link, and based on the selection, the link to embed the video will be altered.

For example, if you click the ‘Start at’ checkbox and give a custom time, the “src” in the tag will be amended with the start time.

Copy and paste the link generated by YouTube into the CodePen, and the resulting webpage will look like the one below.

This is only a high-level overview of the tag, and a lot more customization is available when using it, but it remains out of the scope of this tutorial to handle iframes in Playwright as we will concentrate on handling web pages that contain iframes with Playwright.

Need to calculate SHA256 hashes? Try our SHA256 hash calculator now!

What is the difference between Frames and iFrames?

The and tags represent a way to divide a web page into parts. The major difference between the two is that the frame tag is no longer supported in HTML 5, and iframe is the preferred way to embed content from one website to another.

When you use the tag, then the content of a web page consists of frames that are created by using and tags only (and tag is not used).

<html>
<head>
<title>HTML Frames</title>
</head>
<frameset rows="20%,70%,10%">
   <frame name="top" src="/html/top.html" />
   <frame name="main" src="/html/main.html" />
   <frame name="bottom" src="/html/bottom.html" />
</frameset>
</html>

And when you use , then the content of web page doesn’t contain frames and content of web page is created by using tag (and and tags are not used) as shown below:

<html>
<head>
<title>HTML Iframes</title>
</head>
<body>
<p>See the video</p>
 <iframe width="854" height="480" src="https://www.youtube.com/embed/2eabXBvw4oI"
    frameborder="0"    allowfullscreen>
  </iframe>
</body>
</html>

So just brings some other source’s document to a web page. Frameset tags were used to create frames with the tag frame, whereas iframe fulfills the functions of both frame and frameset tags. Unlike frame tags, iframe tags can also be placed inside the body tags.

Placement of is easy, as a developer can easily put the iframe tag among the other webpage tags and add several iframe tags. On the other hand, placing frame tags in a frameset can be a bit more challenging.

You can also Subscribe to the LambdaTest YouTube Channel and stay updated with the latest tutorials around Selenium testing, Playwright browser testing, CI/CD, and more.

Playwright Frame and FrameLocator

Playwright’s Page class API provides two methods to handle frames in Playwright. These are page.frame() and page.frame_locator().

page.frame()

Returns a frame matching the specified criteria.

To locate the frame using the frame() method, the name or URL of the frame must be supplied to this method. In the example below, you can locate the CodePen name or the page URL.

page.frame_locator()

When working with iframes in Playwright, you can create a frame locator that will enter the iframe and allow selecting of elements in that iframe.

The below code snippet will select the frame with id=’iframe-window’ and search for the text element ‘LAMBDATEST BLOG’.

🛎️The frame and frame_locator() methods are available in all language APIs, but their naming convention might differ slightly. For example, in TypeScript API, frame_locator() is called frameLocator() by the language naming convention. But the functionality and use case remains the same.

Now that you have learned the nuances of frames and iframes in Playwright let’s dive deep into handling iframes in Playwright using Python and TypeScript. The demo will consist of four tests, two using the Python API of Playwright and two using the TypeScript API of Playwright.

You will also see how to run the tests on the Playwright cloud grid provided by LambdaTest.

Looking for a quick difference checker? Check out our tool!

How to set up Playwright with Python?

Before we begin, let us look at how to set up Playwright Python. The first thing you need for any Python project is a dedicated virtual environment to isolate the required dependencies. For this project, let’s create and activate an environment named playwrightiframes.

Next, let’s install Playwright. The packages that need to be installed are shown below and available in the requirements.txt file on the GitHub repo of this code.

And then download all browsers. You can also download specific browsers like Chromium or Firefox instead of downloading them. This step is unnecessary when using a cloud grid like LambdaTest, as LambdaTest will provide the browsers.

All the test scenarios used for the demo in this tutorial on handling iframes in Playwright are compatible with Playwright version 1.33, pytest version 7.3.1, and Python version 3.10.1.

Before moving to the testing scenario, let’s understand the project structure and some important configuration files necessary to run the tests. The project structure looks as below.

Let us now look at the content of each file.

The first file you can see is secrets.env, which is used to store the environment variables that hold the username and API key to access the cloud grid.

The variable RUN_ON controls whether the tests run locally or on a cloud grid.

The variables BROWSER and PLATFORM control the web browser and operating system used when running tests on the cloud grid.

Here is what the complete utilities.py file looks like.

FileName — utitlies.py

from playwright.sync_api import Page
from dotenv import load_dotenv
import os

load_dotenv('secrets.env')
platform = os.getenv('PLATFORM')
browser = os.getenv('BROWSER')
run_on = os.getenv("RUN_ON") or 'local'

def set_test_status(page: Page, status: str, remark: str):
    """
    Function to set stats, title and description of test run on cloud grid
    :param page: instance of Playwright browser page
    :param status: status of test e.g Pass or Failed
    :param remark: additional remark about test status
    """
    page.evaluate(
        "_ => {}",
        "lambdatest_action: {\"action\":\"setTestStatus\", \"\": \status\":\"" + status + "\", \"remark\": \"" + remark + "\"}}"
    )  
capabilities = {
    'browserName': browser,
    'browserVersion': 'latest',
    'LT:Options': {
        'platform': platform,
        'build': 'Testing iFrames using Playwright',
        'name': f'Testing iFrames For {platform} & {browser}',
        'user': os.getenv('LT_USERNAME'),
        'accessKey': os.getenv('LT_ACCESS_KEY'),
        'network': True,
        'video': True,
        'visual': True,
        'console': True,
        'tunnel': False,   # Add tunnel configuration if testing locally hosted webpage
        'tunnelName': '',  # Optional
        'geoLocation': '', # country code can be fetched from https://www.lambdatest.com/capabilities-generator/
    }
}

The utilities.py file is used to store reusable functions. The first line is to import the Page class from the playwright.sync_api. The page class provides methods to interact with the single tab within the browser.

The run_on variable determines if the tests run on a cloud grid or locally. It has been defaulted to run tests locally.

For reading the environment variables, you can use the Python library load_dotenv() and supply to it the ‘secrets.env’ file, which holds all the environment variables.

The set_test_status() function is used to set the final status of the test when running on the cloud grid. It makes use of the evaluate() method of the Page class.

The next reusable bit is the capabilities dictionary, which configures the behavior of the cloud grid such as browser, operating system, name of the build, whether video of test execution will be completed, and screenshots will be captured.

The conftest.py is a special pytest file that contains fixtures that can be globally reused in any pytest file. pytest fixtures can be used to write setup and tear down code necessary to run tests.

We have written two fixtures; the first is named playwright_browser(). It initializes a web browser instance to run locally or establishes a connection to the cloud grid depending on the run_on variable configured in the secrets.env.

The second fixture is named page, and it uses the browser fixture to initialize a web page within the browser to run tests.

By default, the fixture gets the same name as the function’s name, but you can give a different name to the fixture in @pytest.fixture(name=).

Here is what the complete conftest.py file looks like.

FileName — conftest.py

import pytest
from playwright.sync_api import sync_playwright
from utilities.utilities import capabilities, run_on
import subprocess
import urllib
import json

@pytest.fixture(name="browser")
def playwright_browser():    
    if run_on == 'local':
        with sync_playwright() as playwright:
            browser = playwright.chromium.launch(headless=False)
            yield browser

    if run_on == 'cloud':
        with sync_playwright() as playwright:
            playwrightVersion = str(subprocess.getoutput('playwright --version')).strip().split(" ")[1]
            capabilities['LT:Options']['playwrightClientVersion'] = playwrightVersion        
            lt_cdp_url = 'wss://cdp.lambdatest.com/playwright?capabilities=' + urllib.parse.quote(json.dumps(capabilities))
            browser = playwright.chromium.connect(lt_cdp_url)
            yield browser  

@pytest.fixture(name="page")
def page(browser):
    page = browser.new_context().new_page()        
    yield page
    browser.close()

Want to add some fun to your text? Try our shuffle letters tool!

Test Scenario: How to handle nested iFrames in Playwright?

In this scenario, we will check in detail how to handle nested iframes in Playwright.

Implementation

The complete test code is as below.

from playwright.sync_api import expect, Keyboard
from utilities.utilities import set_test_status
import re

def test_nested_iframe_can_be_loaded_correctly(page):
    """
    Test nested iframes can be rendered correctly with the lambdatest blog website.
    Search for blog 'How To Use Playwright For Web Scraping with Python' by author Jaydeep Karale.
    Verify that the blog How To Use Playwright For Web Scraping with Python exists
    Also verify that author profile contains correct link
    """    
    try:
        page.goto('https://codepen.io/jaydeepkarale/pen/dygvXbm')
        base_frame_locator = page.frame_locator("iframe[name=\"CodePen\"]").frame_locator("#frame1")
        base_frame_locator.get_by_placeholder("Enter a url").fill("https://www.lambdatest.com/blog")
        base_frame_locator.get_by_role("button", name="Render iframe").click()
        base_frame_locator.frame_locator('#iframe-window').get_by_placeholder("Search …").fill('How To Use Playwright For Web Scraping with Python')
        page.keyboard.press('Enter')    
        blog_link_locator = base_frame_locator.frame_locator('#iframe-window').get_by_role('link', name='How To Use Playwright For Web Scraping with Python').first
        blog_author_locator = base_frame_locator.frame_locator('#iframe-window').get_by_role('link', name='Jaydeep Karale').first
        expect(blog_link_locator).to_have_attribute('href',re.compile('/blog/playwright-for-web-scraping/'))
        expect(blog_author_locator).to_have_attribute('href','https://www.lambdatest.com/blog/author/jaydkarale/')
        set_test_status(page, 'Passed','Blog exists')
        page.pause()
        page.close()
    except Exception as ex:
        set_test_status(page, 'Failed',str(ex))

Code Walkthrough

Let us now go through the test steps step-by-step.

Step 1

First, navigate to the custom-developed CodePen using the goto() method available as part of the page API.

The CodePen contains two iframes; one iframe renders iframetester.com the second iframe renders the Playwright Python homepage.

Step 2

Next, use the frame_locator() method and supply the id of the frame, in this case, frame1, to form the base locator. All the subsequent elements will be located using this base locator as a reference.

Step 3

In this step, use the base_frame_locator to locate the input field on iframetester using the Playwright locator get_by_placeholder() since the field has a placeholder text ‘Enter a url’ assigned to it.

Fill in the URL of https://www.lambdatest.com/blog, which will redirect to the blog page of LambdaTest. After filling in the URL, you can use the get_by_role() *locator to find the ‘Render iframe’ button and perform a *click() action on it.

The rendered website is shown below.

Step 4

On inspection of the CodePen once more, you can see that the iframe rendered by the iframetester website has an id=’iframe-window’. You can leverage this fact to interact with elements within the iframe.

The element you will locate is the ‘Search’ input field. It has a placeholder text ‘Search …’ which can be used by the Playwright locator get_by_placeholder(), and in the located element, search for the blog ‘How To Use Playwright For Web Scraping with Python’.

The page.keyboard.press(‘Enter’) will simulate pressing enter on the web page.

The search results appear and look like the image shown below.

Step 5

Next, use base_frame_locator to look for the nested by id=’iframe-window’. Within the nested iframe, use the get_by_role() Playwright locator to look for a link to the blog under test.

Since the link is used twice, one for the title of the blog and once for the image of the blog, consider the first located link using the first attribute and assign it to blog_link_locator variable.

The blog author profile is also represented by a link. You can use the get_by_role() Playwright locator and locate the ‘link’ with the text ‘Jaydeep Karale’ and assign it to a variable blog_author_locator.

Step 6

You can use the expect() Playwright assertion to test if the element located by the blog_link_locator has an href attribute ‘/blog/playwright-for-web-scraping.’

Then, use expect() assertion on the blog_author_locator() to test if the author’s profile contains ‘jaydkarale’, the short name of the author.

The set_test_status() method discussed in the utilities.py is used to communicate the test status to the cloud grid if tests run on cloud infra.

Step 7

page.pause()
page.close()

The pause() method in the page class is helpful when debugging tests and is used to pause the execution at this point.

The close() method is called to close the page context.

This completes the first test scenario where you saw how to handle nested iframes using the Playwright frame and frame_locator methods. Let us look at another test scenario to fill in a ‘Book A Demo’ form rendered within an <iframe>.

Convert your text to text lowercase effortlessly using our online tool.

Test Scenario: How to handle Forms within iFrames in Playwright?

Implementation

The complete test code looks as below.

def test_iframe_tester_fill_book_a_demo_form(page):
    """
    Test if iframe renders the lambdatest blog URL correctly.
    Click on Book A Demo and fill the form with company name, firstname, lastname, email and phonenumber    
    """
    try:
        page.goto('https://iframetester.com/')
        page.get_by_placeholder('Enter a url').fill('https://www.lambdatest.com/blog')
        page.keyboard.press('Enter')        
        page.frame_locator('#iframe-window').get_by_role('link', name='Book A Demo', exact=True).click()
        page.frame_locator("internal:text=\"<p>Your browser does not support iframes.</p>\"i").get_by_text("Allow Cookie").click()
        page.frame_locator("internal:text=\"<p>Your browser does not support iframes.</p>\"i").get_by_placeholder("Company Name").fill('Test Company')
        page.frame_locator("internal:text=\"<p>Your browser does not support iframes.</p>\"i").get_by_role("textbox", name="First Name*").fill('Test First Name')
        page.frame_locator("internal:text=\"<p>Your browser does not support iframes.</p>\"i").get_by_role("textbox", name="Last Name*").fill('Test Last Name')
        page.frame_locator("internal:text=\"<p>Your browser does not support iframes.</p>\"i").get_by_role("textbox", name="Work Email*").fill('sample@sample.com')
        page.frame_locator("internal:text=\"<p>Your browser does not support iframes.</p>\"i").get_by_role("textbox", name="Phone Number*").fill('1234567890')
        page.pause()
        set_test_status(page, 'Passed','Form input completed')
        page.close()
    except Exception as ex:        
        set_test_status(page, 'Failed',str(ex))

Code Walk Through

Let us now go through the test cases step-by-step.

Step 1

Load the iframetester website using the page.goto() method. The input field to enter the website is rendered as a placeholder text ‘Enter a url’. You can use this with the Playwright locator get_by_placeholder() to locate the input field and enter the URL of the LambdaTest blog website.

Then, simulate an enter key press using the keyboard.press() method to render the website under test.

Step 2

The iframe within the iframetester website has the id=’iframe-window’, which is used to interact with the website rendered within the iframe.

Within the iframe ‘Book A Demo’ is a link located using the Playwright locator get_by_role() with link as an attribute and perform click() action on it.

Step 3

The ‘Allow Cookie’ button is located and clicked, which makes the ‘Book Demo’ form visible.

Step 4

The form elements are input fields, and you can locate them using the placeholder text by using the get_by_placeholder() locator or get_by_role(‘textbox’). You can see both of them used to demo each locator.

On the located elements, call the fill() method to populate the values.

Execution

First execute the tests locally by setting the variable RUN_ON=local in the secrets.env *file and running the command *pytest -v.

Both tests pass successfully.

For the second test, you can also see the ‘Book A Demo’ form populated with the dummy values you provided in the test case.

To run the tests on a cloud grid, use the cloud grid provided by LambdaTest for Playwright automated testing. For that, amend the secrets.env file to set the RUN_ON=cloud *and the *LT_USERNAME *and *LT_ACCESS_KEY, both of which can be obtained from the LambdaTest Profile Page.

Running the tests using pytest -v, you can see the tests running on the LambdaTest Dashboard. The dashboard clearly shows the status of the tests as configured in the set_test_status() function.

Additional configurations made in the capabilities dictionary in utilities.py, such as the build and name of the tests, are displayed.

Additionally, when you open any test, you can see more information such as video of the execution, screenshots, test status, browser, and operating system where the tests are running.

Give your text a twist with our unique text rotater tool.

How to set up Playwright with TypeScript?

Using Playwright with its Typescript API has its advantages. In terms of installation, there are two ways in which Playwright can be installed, one of them is using the Node.js package manager like npm. The second method is using the Playwright VS Code extension.

Navigate to the extension manager on VS Code and search for Playwright. Then install the official Playwright Test for VS Code, as shown in the image below.

Once the official extension is installed, use the ‘Install Playwright’ action from the command panel to get started.

A successful installation will result in logs that look like the below image.

Successful installation will produce a directory structure that resembles the image shown below.

The tests folder will contain a sample test, and all new tests should be added to this folder only. The package.json will contain the Playwright version, and a demo test app is also included in the test-examples folder.

The playwright.config.ts is an important file generated as part of the installation, which stores the configuration information of where the tests are located

export default defineConfig({
  testDir: './tests',

The reporter to be used to generate reports after tests are run:

reporter: 'html',

Below is the list of browsers and device viewports to run the tests on. We will be later configuring this file to debug tests on mobile viewports. Here are the complete contents of the file.

All the test scenarios used for the demo in this blog are compatible with Playwright version 1.32.2, NodeJS version v18.15.0, and npm version 9.5.0.

The setup required for performing Playwright end-to-end testing with TypeScript locally is completed.

When running the Playwright automation on a cloud grid, additional settings are required, but we will discuss them in the execution part of this tutorial on handling iframes in Playwright a bit later.

Test Scenario: How to handle Ajax response in iFrames in Playwright?

Implementation

The complete test code is below.

test('has success message', async ({ page }, testInfo ) => {  
  /*
  Test if demo email and demo name can be entered in the codepen form and select Gitlab as platform and click Submit.
  On submitting we should be able to verify the success message is displayed
  */  
  await page.goto('https://codepen.io/getform/pen/jRoexL');
  await page.frameLocator('iframe[name="CodePen"]').getByPlaceholder('Enter email').fill('test@test.com');  
  await page.frameLocator('iframe[name="CodePen"]').getByPlaceholder('Enter your name').fill('Test user');
  await page.frameLocator('iframe[name="CodePen"]').getByRole('combobox', { name: 'Favourite Platform' }).selectOption('Gitlab');
  await page.frameLocator('iframe[name="CodePen"]').getByRole('button', { name: 'Submit' }).click();
  await expect(page.frameLocator('iframe[name="CodePen"]').getByText('We received your submission, thank you!')).toBeVisible();
});

Code Walk Through

Let us now go over the test code step by step.

Step 1

The sample CodePen displaying the contact form is shown below.

On the browser page, call the goto() method to navigate to the codepen URL.

Step 2

On inspection, you can see that the form is displayed within an iframe with name=’CodePen’. You can leverage this to enter the iframe using the frameLocator() method.

All other elements within the iframe are then located using the frame as a reference.

Step 3

In the iframe, the input field to enter email has a placeholder ‘Enter email’.

We use the Playwright locator getByPlaceholder() and supply the placeholder text and call the fill(‘test@test.com’) method to enter a dummy email.

Step 4

Like the email field, the name input field is located using the placeholder text and getByPlaceholder() Playwright locator.

The fill() method is used to populate a dummy name, ‘Test user’.

Step 5

The dropdown to select the platform is located using getByRole (‘combobox’, {name:’Favourite Platform’ } ).

Using the selectOption() method, select the ‘Gitlab’ option.

Step 6

‘Submit’ is a button and the getByRole() method is used with a role argument as ‘button’ and name: ‘Submit’.

The click() method is called on the located button to submit the form.

Step 7

The Playwright assertion — expect() *is used to assert the response *text toBeVisible().

Test Scenario: How to handle search within iFrames in Playwright?

Implementation

Here is what the complete test looks like.

test('w3 schools has typescript tutorials', async ({ page }) => {  
  /*
  Test if demo website has a search bar and we are able to search for TypeScript tutorials.
  */
    await page.goto('https://www.w3schools.com/tags/tryit.asp?filename=tryhtml_iframe');
    await page.frameLocator('iframe[name="iframeResult"]').frameLocator('iframe[title="W3Schools Free Online Web Tutorials"]').getByPlaceholder('Search our tutorials, e.g. HTML').fill('typescript');
    await page.frameLocator('iframe[name="iframeResult"]').frameLocator('iframe[title="W3Schools Free Online Web Tutorials"]').getByRole('button', { name: '' }).click();
    await expect(page.frameLocator('iframe[name="iframeResult"]').frameLocator('iframe[title="W3Schools Free Online Web Tutorials"]').getByRole('link', { name: 'Start learning TypeScript now »' })).toBeVisible();
});

Code Walk Through

Let us now go over the step-by-step walkthrough of the code.

Step 1

Navigate to the W3Schools iframe test website by calling the goto() method on the page class.

Step 2

The outer iframe has name=’iframeResult’, and the inner iframe has a title=’W3Schools Free Online Web Tutorials’

You can use chaining to navigate to the inner iframe by using the frameLocator() method twice, once on the outer iframe and then on the inner iframe in Playwright.

In the inner iframe, we use the getByPlaceholder() to locate the search field and fill in the value ‘typescript’ to search for all TypeScript content.

Step 3

The chaining is continued in this step as well to navigate to the inner frame.

Within the inner frame, the search is located by using getByRole(‘button’), and then the click() action is performed.

Step 4

The results contain a ‘Start learning Typescript now’ link.

You can use Playwright assertion expect() to assert this link toBeVisible(), which is a method to assert the visibility of elements on a webpage.

Execution

Let us now run the test locally first on Chromium. For that purpose, you need to enable Chromium in playwright.config.ts file in the project’s array.

Chromium is configured as a JSON object, as shown below:

You can now run the tests using the command:

npx playwright test –project=Chromium

Both the tests are passing successfully, and you can generate a detailed execution summary using the command.

npx playwright show-report

The summary view of the report looks like the one shown below and clearly shows the number of tests run, passed, failed, and skipped.

On clicking an individual test, you can see a more detailed view of the test execution in terms of the test steps and browser engine used.

Let us now look at the execution of the tests on a cloud grid such as LambdaTest. For that purpose, add two new files to your project.

The first file is called ‘.env’, which will store the username and access key required to access the cloud grid. The username and access key can be obtained from the password & security page of LambdaTest.

Add the username and access key to the .env file.

LT_USERNAME=<LT_USERNAME>
LT_ACCESS_KEY=<LT_ACCESS_KEY></LT_ACCESS_KEY>

To ensure that env variables are available for our tests, use the dotenv npm package. It can be installed using the npm install dotenv command.

This dotenv package reads the ‘.env’ file and exports the variables in it to be used in our code whenever needed using process.env.LT_USERNAME or process.env.LT_ACCESS_KEY. The general format remains process.env.< ENV_VARIABLE_NAME >.

The second file you need is the lambdatest-setup.ts. The naming of the file is for reference purposes. It can be named anything as per your preference. Here is what the complete file looks like.

FileName — lambdatest-setup.ts

/**
 * Add the file in your test suite to run tests on LambdaTest.
 * Import 'test' object from this file in the tests.
 */

import * as base from "@playwright/test";
import path from "path";
import { chromium } from "@playwright/test"
import dotenv from 'dotenv';
dotenv.config();

// LambdaTest capabilities
const capabilities = {
  browserName: "Chrome", // Browsers allowed: 'Chrome', 'MicrosoftEdge', 'pw-chromium', 'pw-firefox' and 'pw-webkit'
  browserVersion: "latest",
  "LT:Options": {
    platform: "Windows 10",
    build: "Playwright TypeScript iframes",
    name: "Playwright TypeScript iframes",
    user: process.env.LT_USERNAME,
    accessKey: process.env.LT_ACCESS_KEY,
    network: true,
    video: true,
    console: true,
    tunnel: false, // Add tunnel configuration if testing locally hosted webpage
    tunnelName: "", // Optional
    geoLocation: "US", // country code can be fetched from https://www.lambdatest.com/capabilities-generator/
  },
};

// Patching the capabilities dynamically according to the project name.
const modifyCapabilities = (configName, testName) => {
  let config = configName.split("@lambdatest")[0];
  let [browserName, browserVersion, platform] = config.split(":");
  capabilities.browserName = browserName
    ? browserName
    : capabilities.browserName;
  capabilities.browserVersion = browserVersion
    ? browserVersion
    : capabilities.browserVersion;
  capabilities["LT:Options"]["platform"] = platform
    ? platform
    : capabilities["LT:Options"]["platform"];
  capabilities["LT:Options"]["name"] = testName;
};

const getErrorMessage = (obj, keys) =>
  keys.reduce(
    (obj, key) => (typeof obj == "object" ? obj[key] : undefined),
    obj
  );

const test = base.test.extend({
  page: async ({ page, playwright }, use, testInfo) => {  
    // Configure LambdaTest platform for cross-browser testing
    let fileName = testInfo.file.split(path.sep).pop();
    if (testInfo.project.name.match(/lambdatest/)) {
      modifyCapabilities(
        testInfo.project.name,
        '${testInfo.title} - ${fileName}'
      );
      const browser = await chromium.connect({
        wsEndpoint: 'wss://cdp.lambdatest.com/playwright?capabilities=${encodeURIComponent(
          JSON.stringify(capabilities)
        )}',
      });

      const ltPage = await browser.newPage(testInfo.project.use);
   await use(ltPage);

      const testStatus = {
        action: "setTestStatus",
        arguments: {
          status: testInfo.status,
          remark: getErrorMessage(testInfo, ["error", "message"]),
        },
      };
      await ltPage.evaluate(() => {},
      'lambdatest_action: ${JSON.stringify(testStatus)}');
      await ltPage.close();
      // await browser.close();
    } else {
      // Run tests in local in case of local config provided
      await use(page);
    }
  },
});
export default test;

Let us now understand the contents of the file step by step.

The first few lines in the files are the imports. The two notable imports are the Chromium browser engine from Playwright to support running the tests. The second is the dotenv package, which will help us convert the .env file to environment variables and use them in our code.

The dotenv.config() is the line that reads the ‘.env’ and exposes them as environment variables.

The JSON object capabilities are used to configure the behavior of the cloud grid and supply the username and access key.

The configuration we can make is setting the *browserName, browserVersion, platform *(operating system), enable or disable network and console logs and enable or disable execution video capture.

In the case of locally hosted websites, tunnel to the LambdaTest cloud grid can be also provisioned here.

The next part is configuring the operating system and the browser, which will be used when running the tests on the cloud grid.

A variety of options, such as Linux, macOS, and Windows are available in terms of operating system, and all modern browser engines are supported by LambdaTest cloud grid.

The final part is to override the base ‘Playwright/test’ method to make it compatible with connecting to the cloud grid and running tests. The complete method implementation is as below.

const test = base.test.extend({
  page: async ({ page, playwright }, use, testInfo) => {  
    // Configure LambdaTest platform for cross-browser testing
    let fileName = testInfo.file.split(path.sep).pop();
    if (testInfo.project.name.match(/lambdatest/)) {
      modifyCapabilities(
        testInfo.project.name,
        '${testInfo.title} - ${fileName}'
      );
      const browser = await chromium.connect({
        wsEndpoint: 'wss://cdp.lambdatest.com/playwright?capabilities=${encodeURIComponent(
          JSON.stringify(capabilities)
        )}',
      });

      const ltPage = await browser.newPage(testInfo.project.use);
      await use(ltPage);

      const testStatus = {
        action: "setTestStatus",
        arguments: {
          status: testInfo.status,
          remark: getErrorMessage(testInfo, ["error", "message"]),
        },
      };
      await ltPage.evaluate(() => {},
      'lambdatest_action: ${JSON.stringify(testStatus)}');
      await ltPage.close();
      // await browser.close();
    } else {
      // Run tests in local in case of local config provided
      await use(page);
    }
  },
});

Let us understand the method in detail by doing a step-by-step walkthrough.

The testInfo is a special Playwright variable that contains information about the currently running test. Extract the name of the TypeScript file that contains the tests.

Next, use the testInfo to determine the name of the project, which is configured in the playwright.config.ts projects array. If the name contains the word ‘lambdatest’, then run the tests on the cloud grid else locally.

The snapshot below shows how the project’s array looks to run the tests on a cloud grid. We have configured the cloud grid to provide Windows 10 & Chrome latest version as the running environment.

The connect method is used to supply the URL to connect to the cloud grid, and also provided to it is the capabilities object configured to run the tests and contains the username and access key. This returns a browser object.

Using the browser object, you can create a web page.

The testStatus method is used to set the test status i.e., either success or fail on the cloud grid.

In the file containing the test, we wrote testiframes.spec.ts. You can now import the test method. This is how the complete file looks now.

FileName — testiframes.spec.ts

import { expect } from '@playwright/test';
import test from "../lambdatest-setup";

test('has success message', async ({ page }, testInfo ) => {  
  /*
  Test if demo email and demo name can be entered in the codepen form and select Gitlab as platform and click Submit.
  On submitting we should be able to verify the success message is displayed
  */  
  await page.goto('https://codepen.io/getform/pen/jRoexL');
  await page.frameLocator('iframe[name="CodePen"]').getByPlaceholder('Enter email').fill('test@test.com');  
  await page.frameLocator('iframe[name="CodePen"]').getByPlaceholder('Enter your name').fill('Test user');
  await page.frameLocator('iframe[name="CodePen"]').getByRole('combobox', { name: 'Favourite Platform' }).selectOption('Gitlab');
  await page.frameLocator('iframe[name="CodePen"]').getByRole('button', { name: 'Submit' }).click();
  await expect(page.frameLocator('iframe[name="CodePen"]').getByText('We received your submission, thank you!')).toBeVisible();
});

test('w3 schools has typescript tutorials', async ({ page }) => {  
  /*
  Test if demo website has a search bar and we are able to search for TypeScript tutorials.
  */
    await page.goto('https://www.w3schools.com/tags/tryit.asp?filename=tryhtml_iframe');
    await page.frameLocator('iframe[name="iframeResult"]').frameLocator('iframe[title="W3Schools Free Online Web Tutorials"]').getByPlaceholder('Search our tutorials, e.g. HTML').fill('typescript');
    await page.frameLocator('iframe[name="iframeResult"]').frameLocator('iframe[title="W3Schools Free Online Web Tutorials"]').getByRole('button', { name: '' }).click();
    await expect(page.frameLocator('iframe[name="iframeResult"]').frameLocator('iframe[title="W3Schools Free Online Web Tutorials"]').getByRole('link', { name: 'Start learning TypeScript now »' })).toBeVisible();
});

Since you have seen the execution of both tests locally and on the cloud grid, we will demo a single running of a single test, ‘w3 schools has typescript tutorials’.

Leveraging cloud grids provided by LambdaTest, an AI-powered test orchestration and execution platform, for running Playwright tests provide advantages such as scalability and availability of multiple operating systems and browsers to understand the test behavior on a wide range of test setups.

Run the command npx playwright test -g “w3 schools has typescript tutorials”.

Here is how a successfully run test will look on the LambdaTest Dashboard.

On clicking the test, we can also see a detailed view of the test, such as the execution video, the actionability logs, the operating system, and the browsers used.

The npx playwright show-report command also shows the details of the test execution as before.

This completes the execution of the test on the cloud grid.

Playwright automation is straightforward to grasp, requiring only fundamental knowledge of Python and TypeScript. If you’re interested in mastering test execution through Playwright automation, LambdaTest offers a complimentary Playwright 101 certification to enhance your automation testing abilities.

Conclusion

In this tutorial on handling iframes in Playwright, you have seen in detail how you can use Playwright to handle frames using its Python and TypeScript API. You have also had a look at what the use case is for frames and what is the distinction between the HTML tags frame and iframe.

Since HTML 5 iframe is the preferred way of embedding content from other websites into our own, you also learned how to embed a YouTube video within a custom-developed iframe.

Iframes in Playwright provide a convenient way of embedding content from other sources such as YouTube, Twitter, and Google, and even placing advertisements, their usage can provide better modularity to our website. Hence, reliably testing websites containing iframes is key to delivering a better user experience.

You also learned scenarios of nested iframes in Playwright, and you can test them using Python and TypeScript.

The execution of the tests was covered locally as well as on a cloud grid. The advantage of using a cloud grid for automation testing is that time and cost can be saved on setting up various cross platform and cross browser environments. All that is needed is a simple configuration setup, and the desired operating system and browser configuration are available for running the tests.

This provides more confidence to QA and Automation teams by ensuring that the user experience remains the same across different browsers and operating systems.

Playwright Docker Tutorial: Detailed Guide With Example

Jaydeep Karale — Mon, 22 Jan 2024 10:33:42 +0000

OVERVIEW

As software development advanced, software became better, but so did the demands. The tech industry has gone from deploying to production once in 6 months to deploying 6 times daily. With Agile development methodologies leading the way, software development has advanced at lightning speeds, but there’s always a catch.

“It works on my machine” is a common problem when it comes to software development and testing. Simply put, code and tests written on the developers’ local machines sometimes fail to execute on the machines of testers, fellow developers, or even in production, hampering the software development and testing.

As businesses demanded shipping features faster and reduced time to market, tech teams needed now more than ever to find solutions to the problem of running code consistently across the team and environments.

For context, companies like Amazon, Google, and Netflix deploy to production 1000s of time per day (aggregated over the 100s of services that comprise their production environment). While most companies don’t need to deploy at the rate of these tech giants, deploying once or twice per week is now the new normal. And to achieve this deployment rate, there is less and less scope for team members to say, “It doesn’t work on my machine.”

Docker is a platform that allows developers to create and manage applications in containers, which are lightweight and portable environments. With Docker, we can quickly set up and test applications in isolated environments without worrying about compatibility issues. These containers can be easily shared with others and deployed to different environments, making it an efficient way to manage applications at scale.

Not only does Docker solve the puzzle of running software consistently and at scale, but it also provides the necessary means to set up at scale, high quality, high speed, and resilient automated testing. Since the testing team no longer has to worry about setting up code to run locally, the time saved can be invested in writing better end-to-end automation tests, which ensures high-quality software delivery by catching defects early.

Playwright, a library for automated end-to-end browser testing, and Docker, a platform for running applications in containers, provide a powerful solution for developers looking to streamline their testing process. By combining Playwright and Docker, developers can confidently create, test, and deploy their applications, knowing they will run consistently on any machine.

In this Playwright Docker tutorial, we will dive deep into how Playwright and Docker can be used together. When paired together, it can simplify browser testing and improve the reliability and speed of test automation. It can also reduce the time and resources required for testing complex web applications.

Introduction To Docker

Fun Fact !!! The story of Docker can be traced back to the shipping industry and the development of standardized shipping containers in the mid-20th century. Before standardized containers, the cargo was loaded and unloaded by hand, making shipping slow and inefficient.

But with the introduction of standardized containers, it became possible to load and unload cargo using cranes and other machinery, reducing shipping times and costs. This revolutionized the shipping industry, making it possible to move goods more quickly and efficiently than ever before.

On similar lines, Docker revolutionized the world of software development by introducing a standardized, container-based approach to packaging, distributing, and running applications.

Like shipping containers, Docker containers enable developers to move applications quickly and efficiently between different environments, from development to testing to production, making it easier to develop and deploy software at scale.

What Problem Does Docker Solve?

Before implementing end-to-end testing using Playwright Docker, it’s important to understand what problem Docker solves. Let’s now understand them.

Isolated Execution Environments

With software development becoming accessible to anyone with a laptop and an Internet connection, the differentiating factor now is a shorter time to market and faster feature shipping. And to achieve this, it’s important to provide isolated yet consistent execution for teams.

This is where Docker comes in. Docker is a powerful containerization platform that allows developers to package their applications and dependencies into a portable container that can be easily deployed across different environments. It eliminates the challenges of testing across different environments, ensuring that code runs consistently across all machines.

Streamlining Testing

Docker has become an essential tool for software testing. It provides a way to streamline the application testing process, eliminating the need for complex installation procedures and compatibility issues.

It also enables developers to easily spin up multiple instances of an application in different environments, making it easier to identify and fix bugs before deployment.

Scaling With Reliability And Consistency

Not only does Docker solve consistency issues, but it solves them at scale. Docker orchestration is the process of managing, deploying, and scaling Docker containers. With orchestration tools like Kubernetes, Docker Swarm, and Amazon ECS, we can easily manage many containers and automatically scale them up or down, depending on demand.

This solves the scaling issue that arises when we need to handle a sudden increase in traffic or workload. With Docker orchestration, we can ensure that the containers are always running at optimal capacity, providing a seamless and efficient user experience.

Faster Feature Shipping

In the competitive world of software development, time-to-market and faster feature shipping can be the differentiating factor. Docker’s ability to package applications and dependencies into portable containers enables developers to ship features faster.

By providing consistent and isolated code execution environments. This leads to increased efficiency and faster time-to-market.

Convert your data effortlessly with our CSV to XML tool! Try it now

Docker Architecture

Docker consists of a client-server architecture, where the Docker client communicates with the Docker daemon to build, run, and manage containers.

Before we proceed with the installation and writing of tests, let’s first understand the Docker Architecture.

Docker Client

The Docker client (docker) is the primary way many Docker users interact with Docker. When we use commands such as docker run, the client sends these commands to dockerd, which carries them out.

The Docker command uses the Docker API. The Docker client can communicate with more than one daemon.

Docker Host

Docker Host refers to a physical or virtual machine running the Docker engine. The Docker host provides the infrastructure needed to run Docker containers, such as the operating system, storage, networking, and other resources.

The Docker daemon runs on the host machine and manages container images, networks, and storage volumes.

Docker Registry

Docker Registry is a central storage for Docker images. Docker Hub is the preferred registry for Docker, but it’s entirely possible to have your private registry.

Whenever we fire docker pull or push commands, the images are retrieved or stored from the Docker registry.

Docker Objects

Working with Docker involves creating and using images, containers, networks, and volumes. It’s essential to understand these before we proceed.

Docker Images

Docker images are read-only templates that contain everything needed to run an application, including the application code, runtime environment, libraries, and dependencies. Images are built using a Dockerfile, which defines the components and configuration of the application.

Images are stored in a registry and can be easily shared and reused across different environments. Pre-built images can also be downloaded from Docker Hub using the docker pull command. A sample screenshot showing the download of the Python Docker image is below.

Docker Containers

Docker containers are lightweight, standalone, and executable packages containing an application and all its dependencies (e.g., binaries, packages, libraries, etc.). Containers are created from images and run in a loosely isolated environment, providing isolation and security for the application.

Containers can be easily started, stopped, and managed. They are also designed to be ephemeral, with no persistent state.

Transform YAML to JSON seamlessly using our online converter! Get started today!

Docker Networking

Docker networking enables containers to communicate with each other and the outside world, providing connectivity and flexibility for containerized applications. Containers can be connected to different networks, including default, custom, and overlay networks, depending on applications.

Docker also provides various networking tools and plugins, including DNS, load balancing, and software-defined networking (SDN).

Docker Storage

Docker storage offers a range of options for managing and persisting data in containers, including volumes, bind mounts, and tmpfs mounts. Volumes are the preferred way to manage data in Docker, providing persistent storage that can be shared between containers and preserved even when a container is deleted.

Docker also offers a range of storage plugins and drivers, including support for storage systems like Network File System(NFS), Amazon Elastic Block Store(EBS), and more.

A Quick Word About Open Container Initiative (OCI).

As containerization gained popularity and its adoption started to increase, in 2015, a group of industry leaders, including Docker, CoreOS, and Red Hat, came together to form the OCI, or the Open Container Initiative.

At the time, the container ecosystem was fragmented, with different vendors and platforms offering their proprietary container formats and runtimes. This made it difficult for developers to move containerized applications between different environments and added complexity to the containerization process.

The goal of OCI is to standardize how containers are built and run across different platforms, making it easier to move containerized applications between different environments.

How To Install Docker On Windows?

For this Playwright Docker tutorial, we are using a Windows machine for the demonstration. Some of the below-mentioned steps might not be applicable when using Docker on macOS.

Here are the quick steps for installing Docker on Windows:

Enabling WSL2, Hyper-V, and Virtualization

Based on the OS, Docker allows us the choice of the virtualization backend, i.e., we can either choose WSL2 (Windows Subsystem For Linux) or Hyper-V. Docker is designed to run on Linux-based machines. Hence, it runs without any additional macOS installation but needs the WSL installation on Windows.

Hyper-V is a full-fledged virtualization technology that allows us to create and manage virtual machines on a Windows system, while WSL2 is a lightweight virtualization technology that enables running a Linux distribution natively on a Windows system, primarily for developers who want to use Linux tools and applications on a Windows system.

With that out of the way, let’s see the Windows version we are running on. To check the version, navigate to Windows Explorer, right-click on PC, and click Properties. We are running a Windows 10 Home Edition as seen from the image below:

Based on the Windows version below is the choice of the virtualization backends.

WLS2 Backend

Windows 11 64-bit: Home or Pro version 21H2 or higher, or Enterprise or Education version 21H2 or higher.
Windows 10 64-bit: Home or Pro 21H1 (build 19043) or higher, or Enterprise or Education 20H2 (build 19042) or higher.

Hyper-V Backend

Windows 11 64-bit: Pro version 21H2 or higher, or Enterprise or Education version 21H2 or higher.
Windows 10 64-bit: Pro 21H1 (build 19043) or higher, or Enterprise or Education 20H2 (build 19042) or higher.

The process to enable WSL2, Hyper-V, and Virtualization is similar. Open the Run (Windows + r) and type optionalfeatures.exe

On the subsequent screen that opens, based on the OS version, enable either Virtual Machine Platform and WSL2 or Hyper-V

This completes the prerequisites of WSL2 and the Hyper-V setup needed to install Docker. In the next step of this Playwright Docker tutorial, we proceed to install Docker Desktop, the application necessary for creating and managing Docker containers.

Installing Docker Desktop

Docker Desktop is an application for creating and managing Docker containers on the computer. It provides a graphical user interface and command-line interface for working with containers. Let’s proceed with downloading Docker for windows Docker for windows. After downloading, follow the step-by-step installation guide.

The downloaded installation package will be verified first.

Once the package verification is completed unpacking and installation will start.

If everything goes well, we should see the following Installation succeeded prompt.

To use the Docker Desktop, we must sign up on Docker Hub and create an account. After signing up, start the Docker Desktop from the Windows start menu. Upon starting it, we need to log in using the account we created on Docker Hub.

Once logged in, Docker will attempt to start, and we should see a screen as shown below:

Need to convert HTML to CSV? Our free tool makes it a breeze! Check it out now!

Troubleshooting Tip 💡 WSL1 To WSL2 Upgrade

If the screen freezes at this point, i.e., Docker Desktop starting… prompt doesn’t go away, it’s most probably because the machine does not have the WSL 2. We need to upgrade from WSL1 to WSL2.

Run the below set of commands in the Windows PowerShell command prompt or the newly launched Windows Terminal as per preference.

wsl -l -v to view the WSL version. We can see WSL version 1 exists, but we need version 2.

*wsl — update *(to update to version 2).

wsl –set-default-version 2 (to set 2 as the default version).

Once done, run the wsl -l -v command again and restart the Docker desktop.

After completing all the steps mentioned till this point, a successfully running Docker installation will look as shown in the below image.

Check the settings, and based on the Windows version, there will be options to select the backend. It defaults to WSL 2 as we are running Windows 10 Home version.

“Streamline your software development and integration process with the LambdaTest Docker integration. Seamlessly incorporate software applications into your current workflows”

Brief Introduction To Playwright

Playwright is an end-to-end web testing and browser automation framework. It is immensely helpful for writing test cases for both modern, i.e., dynamic and static web apps.

At the time of writing this Playwright Docker tutorial, the latest stable version of Playwright is 1.28.0, and Playwright is now consistently hitting the > 20K download per day mark, as seen from PyPi Stats.

Below are the download trends of Playwright compared to a popular alternative, Selenium, taken from Pip Trends.

A key consideration to make when using any language, tool, or framework is the ease of its use.

Key features of Playwright

Playwright supports all major browsers, including Chromium, Firefox, Microsoft Edge, and WebKit
Playwright’s APIs are available in various programming languages, such as Python, Java, JavaScript, TypeScript, and .NET
Playwright is a cross-platform tool that works seamlessly on Windows, macOS, and Linux in both headless and non-headless modes
Playwright’s auto-wait feature eliminates the need for artificial timeouts, making tests more robust and less prone to errors.
Playwright includes a codegen tool that helps locate elements with ease.
Playwright Locators provide easy APIs for finding elements on websites.

In the next section of this Playwright Docker tutorial, we will learn how to set up Playwright for Python.

Setting Up Playwright For Python

Playwright is a powerful tool that allows you to automate browser tasks such as filling out forms, clicking buttons, and scraping data from web pages. It supports multiple programming languages, including Python. In this Playwright Docker tutorial, we will go through the steps to set up Playwright for Python so you can start automating your browser tasks.

First, create a dedicated folder for the project called Docker Playwright (This step is not mandatory but is good practice).
Inside the folder we just created, use the built-in venv module to create a virtual environment named docker playwright.

Activate the virtual environment by calling the activate script.
Install the Playwright module using pip install pytest-playwright.
Lastly, install the required browsers using playwright install.

All the tests in this Playwright Docker tutorial have been thoroughly tested on the following versions.

Docker 20.10.22, build 3a2c30b
Python 3.9.12
Pytest 7.2.1
Playwright 1.30.0

Easily convert ASCII to Binary with our online tool! Give it a go!

Project Structure

We will be using the LambdaTest eCommerce Playground for writing the tests. Before moving to dockerizing them, let’s check each in detail and execute them locally without Docker. We will write a total of 8 tests designed to test various functions across 3 different pages on the test website.

To make the test suite structured, easy to extend, and maintain, we will use the Page Object Model (POM) design pattern to arrange the tests. Here is what the project directory structure looks like.

Let’s understand the structure in brief first

The pages folder contains python files for each page. Each file contains a class we want to abstract This structure allows the code to remain organized and increases reusability.
The tests folder contains the test cases which we want to run. These are again segregated based on the page that they will be testing. The name of this folder is in accordance with the pytest requirement.
The utilities folder contains a single utilities.py where we can add all the reusable supporting code.
The docker-compose.yaml contains the code to help build the Docker container effectively in case of a multi-container setup.
The Dockerfile contains the build of the Docker image from the code.
The requirements.txt contains all the Python packages we will need to run the code.
secrets.env is where we abstract the environment variables to control the test runs, browsers, operating systems used, etc.

Implementation (Fixtures & Configuration)

Let us now look at the implementation of the environment file, configuration file, and fixtures file. The environment variables control the test execution environment.

The configuration file contains reusable utilities and the special conftest.py file that allows us to define and share fixtures, hooks, and plugins across multiple test files.

secrets.env

The first supporting file we need to run the code is the secrets.env. This file controls the environment we run the code on, i.e., local or cloud. Username and Access Key of the cloud grid provider. It also controls the Operating system and Browser where the tests will run.

utilities.py

All the reusable code which supports the running of the tests and is called from multiple places within the main script is put in the utilities.py file. The dotenv Python package reads key-value pairs from the .env file and sets them as an environment variable. This is done by calling load_dotenv(‘secrets.env’).

The three lines after that are used to read the environment variables values, i.e., operating system, browser, and the environment, i.e., cloud or local. The tests will be defaulted to run locally.

from playwright.sync_api import Page
from dotenv import load_dotenv
import os


load_dotenv('secrets.env')
platform = os.getenv('PLATFORM')
browser = os.getenv('BROWSER')
run_on = os.getenv("RUN_ON") or 'local'

The set_test_status function is used to set the results of the test execution when running the code on a cloud grid. When running locally, this function does not do anything.

def set_test_status(page: Page, status: str, remark: str):
    """
    Function to set stats, title and description of test run on cloud grid
    :param page: instance of Playwright browser page
    :param status: status of test e.g Pass or Failed
    :param remark: additional remark about test status
    """
    page.evaluate(
        "_ => {}",
        "lambdatest_action: {"action": "setTestStatus", "arguments": {"status":"" + status + "", "remark": "" + remark + ""}}"

The capabilities dictionary is used to configure the test environment when running on a cloud grid. The most notable configurations are the Platform, i.e., the Operating system and the browser. Both these are controlled using environment variables defined in secrets.env.

capabilities = {
    'browserName': browser,
    'browserVersion': 'latest',
    'LT:Options': {
        'platform': platform,
        'build': 'Playwright Docker Demo Build',
        'name': f'Playwright Docker Test For {platform} & {browser}',
        'user': os.getenv('LT_USERNAME'),
        'accessKey': os.getenv('LT_ACCESS_KEY'),
        'network': True,
        'video': True,
        'visual': True,
        'console': True,
        'tunnel': False,   # Add tunnel configuration if testing locally hosted webpage
        'tunnelName': '',  # Optional
        'geoLocation': '', # country code can be fetched from https://www.lambdatest.com/capabilities-generator/
    }
}

conftest.py

Pytest fixtures are a powerful feature of the pytest testing framework that allows us to organize and manage the test code in a more efficient and reusable way. Essentially, pytest fixtures are reusable pieces of code that provide data or resources to the test functions.

This can include pre-populating a database with test data, creating and configuring objects that the tests depend on, or mocking external APIs to simulate certain behaviors.

conftest.py is a special file in pytest that allows us to define fixtures and other configuration options that can be shared across multiple tests. This naming convention is mandatory; otherwise, pytest will not be able to locate the fixtures.

By placing conftest.py in the tests directory, we can make the fixtures and configuration options defined in it available to all test functions and modules in that directory and its subdirectories.

Fixtures are defined using the same syntax as a normal function and decorating the function with the @pytest.fixture decorator. Optionally we can also give the fixture a name. In this case, we have given it the name browser because we are using it to return a Playwright browser instance.

import pytest
import os
from playwright.sync_api import sync_playwright
from utilities.utilities import capabilities, run_on
from pages import homepage, accountpage, productpage
import subprocess
import urllib
import json




@pytest.fixture(name="browser")
def playwright_browser():
    print(run_on)
    if run_on == 'local':
        with sync_playwright() as playwright:
            browser = playwright.chromium.launch(headless=True)
            yield browser

    if run_on == 'cloud':
        with sync_playwright() as playwright:
            playwrightVersion = str(subprocess.getoutput('playwright --version')).strip().split(" ")[1]
            capabilities['LT:Options']['playwrightClientVersion'] = playwrightVersion        
            lt_cdp_url = 'wss://cdp.lambdatest.com/playwright?capabilities=' + urllib.parse.quote(json.dumps(capabilities))
            browser = playwright.chromium.connect(lt_cdp_url)
            yield browser

The next three fixtures we have defined are for providing a page instance. All three fixtures take in the fixture defined above as input and create a Playwright page instance. Using this Page instance, we initialize the respective Page Object and yield it.

@pytest.fixture
def account_page(browser):
    page = browser.new_context().new_page()    
    account_page = accountpage.AccountPage(page)
    yield account_page


@pytest.fixture
def home_page(browser):
    page = browser.new_context().new_page()    
    home_page = homepage.HomePage(page)
    yield home_page


@pytest.fixture
def product_page(browser):
    page = browser.new_context().new_page()    
    product_page = productpage.ProductPage(page)
    yield product_page

This completes the setup code walkthrough, and we are now ready to see the actual tests.

Want to convert ASCII to Hex? Try our simple online converter now

Implementation (POM & Tests)

The test suite is going to consist of 8 tests in total which test functionality of 3 different pages:

Home page
My account page
Product page

As shown in the project structure, we will create a .py file under pages directory, which represents the class object for each page under test. So, homepage.py will define the code corresponding to the Home page, accountpage.py will define the code corresponding to the My account page, and productpage.py will define the code corresponding to the Product page.

This approach ensures that the code remains organized, is easy to maintain, and also easy to extend for adding more tests in the future.

Test Scenarios (Homepage)

We will write two test scenarios for the Home page, defined below.

The Home page should contain the ‘SEARCH’ button and be visible.
The Home page should contain the ‘My account’ link and URL to navigate to the Account section.

Code Walkthrough (pages/homepage.py)

On inspecting the Home page, we can see that the ‘SEARCH’ has a button role.

And that ‘My account’ is a link that contains the href attribute.

from playwright.sync_api import expect
from utilities.utilities import set_test_status


class HomePage:  
   def __init__(self, page):
        self.page = page
        self.search_button_locator = page.get_by_role(role="button", name="Search")
        self.myaccount_link_locator = page.get_by_role(role="link", name="My Account")

Step 1: We define a class HomePage where we will group all the code.

Step 2: The init.py method takes an instance of a Playwright page as a parameter, and using that, we define two Playwright locators as instance attributes.

Step 3: Search has a button role with the name ‘Search’ we use the get_by_role() locator to locate it and store it in an instance attribute search_button_locato

Step 4: My account has a link role with the name ‘My Account’ we can again use get_by_role() locator to locate it and store it in an instance attribute myaccount_link_locator

def navigate(self):
        self.page.goto("https://ecommerce-playground.lambdatest.io/")

navigate() method defined in the HomePage class calls the goto() method on the Playwright page instance and navigates to the home page URL supplied to it

def search_button(self):                
        try:
            expect(self.search_button_locator).to_be_visible()
            set_test_status(self.page, "Passed", "Search button is visible")
        except Exception as ex:
            set_test_status(self.page, "Failed", "Search button is not visible")

Step 1: The search_button() method then calls the Playwright except() *assertion to verify if the element located by *search_button_locator is visible

Step 2: The set_test_status() method defined in the utilities.py is called then to inform the cloud grid of the status of the test if running on cloud grid

def myaccount_link(self):        
        try:
            expect(self.myaccount_link_locator).to_have_attribute("href", "https://ecommerce-playground.lambdatest.io/index.php?route=account/account")
            set_test_status(self.page, "Passed", "My account link is visible")
        except Exception as ex:
            set_test_status(self.page, "Failed", "My account link is not visible")

Step 1: The myaccount_link() method then calls the Playwright except() assertion on the instance attribute myaccount_link_locator to expect it to have href attribute with the link for account section. You can learn more about it through this tutorial on Playwright assertions.

Step 2: The set_test_status() method defined in the utilities.py is called to inform the cloud grid of the status of the test if running on the cloud grid.

Code Walkthrough (tests/test_homepage.py)

The class file homepage.py contains all the location and assertion codes. All that remains to write in the test_homepage.py is to call the methods defined by creating an object of the Homepage class. We have abstracted this object creation in the fixture home_page() defined in the conftest.py discussed above.

from playwright.sync_api import expect
from utilities.utilities import set_test_status
from pages.homepage import HomePage


def test_homepage_contains_search_button(browser, home_page):
    """
    Test to verify if search button exists on the home page
    """    
    home_page.navigate()
    home_page.search_button()
    browser.close()

Step 1: The test_homepage_contains_search_button() takes in browser and home_page fixtures.

Step 2: Using the home_page, we call the navigate() method to open the home page.

Step 3: On the opened homepage, call the search_button() method, which contains the test logic.

def test_homepage_contains_myaccount_link(browser, home_page):
    """
    Test to verify if my account link exists on the home page
    """        
    home_page.navigate()  
    home_page.myaccount_link()            
    browser.close()

Step 1: The takes in browser and home_page fixtures.

Step 2: Using the home_page, we call the navigate() method to open the home page.

Step 3: On the opened homepage, call the myaccount_link() method, which contains the test logic.

Step 4: We close the browser by calling browser.close() to ensure the release of resources.

Test Scenarios (Account Page)

We will write three test scenarios for the account page defined below.

The Account page should contain a registration link for new customers.
The Account page should contain the Email & Password field in the login form for returning customers.
The Account page should contain the Forgotten Password link.

Code Walkthrough (pages/account.py)

On inspecting the account page, we can see that New Customer Registration has a role link with the name Continue and href attribute to redirect to registration.

The Returning Customer form has fields for email & password with placeholders ‘E-Mail Address’ and ‘Password’.

Inspecting the Forgotten Password shows that it has the role link with the href attribute redirecting to the forgotten password.

from playwright.sync_api import expect
from utilities.utilities import set_test_status


class AccountPage:

    def __init__(self, page):
        self.page = page
        self.new_registration_link_locator =  page.get_by_role(role="link", name="Continue")
        self.email_field_locator = page.get_by_placeholder("E-Mail Address")
        self.password_field_locator =  page.get_by_placeholder("Password")
        self.forgotten_password_link_locator = page.get_by_role(role="link", name="Forgotten Password", exact=True)

Step 1: We define a class AccountPage where we will group all the tests related to the My Account page.

Step 2: The init.py method takes in an instance of a Playwright page as a parameter, and using that, we define four Playwright locators in it as instance attributes.

Step 3: New Registration has a link role with the name ‘Continue’, so we use the get_by_role() Playwright locator to locate it and store it in an instance attribute new_registration_link_locator.

Step 4: Since the login form field email has a placeholder ‘E-Mail Address,’ we use the Playwright locator get_by_placeholder() and store the located element in an instance attribute email_field_locator.

Step 5: The login form field password has a placeholder ‘password’, so we use the Playwright locator get_by_placeholder() and store the located element in an instance attribute password_field_locator.

Step 6: Also, the ‘Forgotten Password’ has a link role, so we can use the get_by_role() Playwright locator and store it in an instance attribute forgotten_password_link_locator.

def navigate(self):
        self.page.goto("https://ecommerce-playground.lambdatest.io/index.php?route=account/login")

The navigate() method defined in the AccountPage class calls the goto() method on the Playwright page instance and navigates to the account page URL supplied to it.

def new_registration(self):                
        try:
             expect(self.new_registration_link_locator).to_have_attribute("href", "https://ecommerce-playground.lambdatest.io/index.php?route=account/register")
             set_test_status(self.page, "Passed", "Registration link is visible")
        except Exception as ex:
            set_test_status(self.page, "Failed", "Registration link is not visible")

Step 1: The new_registration() method then calls the Playwright except() assertion on the instance attribute new_registration_link_locator and verifies if it has an href attribute and the link points to the registration endpoint.

Step 2: The set_test_status() method defined in the utilities.py is called to inform the cloud grid of the status of the test if running on the cloud grid.

def login_form(self):                
        try:
            expect(self.email_field_locator).to_be_visible()
            expect(self.password_field_locator).to_be_visible()
            set_test_status(self.page, "Passed", "Login form contains email & password fields")
        except Exception as ex:
            set_test_status(self.page, "Failed", "Login form does not contains email & password fields")

Step 1: The login_form() method is where we use the expect() Playwright assertion to verify that the elements located by email_field_locator and password_field_locator are visible.

Step 2: The set_test_status() method defined in the utilities.py is called to inform the cloud grid of the test status if running on the cloud grid.

def forgotten_password(self):                
        try:
         expect(self.forgotten_password_link_locator).to_have_attribute("href","https://ecommerce-playground.lambdatest.io/index.php?route=account/forgotten")    
            set_test_status(self.page, "Passed", "Forgotten Password link is visible")
        except Exception as ex:
            set_test_status(self.page, "Passed", "Forgotten Password link is not visible")

Step 1: The forgotten_password() method is where we expect() that the located forgotten_password_link_locator to have an href attribute with the specific link.

Step 2: The set_test_status() method defined in the utilities.py is called to inform the cloud grid of the status of the test if running on the cloud grid.

Code Walkthrough (tests/test_accountpage.py)

The class file accountpage.py contains all the element locations and assertion code. All that remains to write in the test_accountpage.py is to call the methods defined by creating objects of the class AccountPage.

We have abstracted this object creation in the fixture account_page() defined in the conftest.py discussed above.

from playwright.sync_api import expect
from utilities.utilities import set_test_status
from pages.accountpage import AccountPage


def test_myaccount_page_contains_registration_link(browser, account_page):
    """
    Test to verify if new customer registration link exists on account page
    """
    account_page.navigate()
    account_page.new_registration()
    browser.close()

Step 1: The test_myaccount_page_contains_registration_link() takes in browser and account_page fixtures as parameters and using account_page, we call the navigate() method to open the account page.

Step 2: This is followed by calling the new_registration() method, where we assert the registration link to be present.

def test_myaccount_page_contains_login_form_with_email_and_password(browser, account_page):
    """
    Test to verify if customer login form exists on account page and contains email and password fields
    """      
    account_page.navigate()  
    account_page.login_form()            
    browser.close()

Step 1: The test_myaccount_page_contains_login_form_with_email_and_password() takes in browser and account_page fixtures as parameters.

Step 2: We use the account_page, which is nothing but an instance of the AccountPage class, to call the navigate() method to open the account page.

Step 3: This is followed by calling the login_form() method, where we assert email & password fields to be visible to be present.

def test_myaccount_page_contains_forgotten_password_link(browser, account_page):
    """
    Test to verify if forgotten password link exists on account login page
    """      
    account_page.navigate()  
    account_page.forgotten_password()            
    browser.close()

Step 1: The test_myaccount_page_contains_forgotten_password_link() takes in browser and account_page fixtures as parameters.

Step 2: We use the account_page, which is nothing but an instance of the AccountPage class, to call the navigate() method to open the account page.

Step 3: This is followed by calling the forgotten_password() method, where we assert it to be a link with the href attribute.

Step 4: Close the browser by calling the browser.close() ensures the release of resources.

Test Scenarios (Product Page)

We will write three test scenarios for the product page defined below.

The Product page should contain an ‘Add To Cart’ button.
The Product page should contain a ‘Buy Now’ button.
The Product page should contain a checkout where the option to use coupon code exists.

Code Walkthrough (pages/productpage.py)

Inspection of ‘ADD TO CART’ shows that it has a button role and is named ‘Add to Cart’

Inspection of ‘BUY NOW’ shows that it has a button role and is named ‘Buy now’.

Inspection of the coupon code input field shows that it has a placeholder ‘Enter your coupon here’.

Based on the inspection, we can now write the page object ProductPage which abstracts all details necessary to run the tests.

from playwright.sync_api import expect
from utilities.utilities import set_test_status
import re


class ProductPage:

    def __init__(self, page):
        self.page = page
        self.addtocart_button_locator = page.get_by_role(role="button", name=re.compile("add to cart", re.IGNORECASE))
        self.buynow_button_locator = page.get_by_role(role="button", name=re.compile("buy now", re.IGNORECASE))

Step 1: The page object class is called ProductPage since it deals with tests for information on the product.

Step 2: The init.py method takes in an instance of a Playwright page as a parameter, and using that, we define two Playwright locators as instance attributes.

def navigate(self):
        self.page.goto("https://ecommerce-playground.lambdatest.io/index.php?route=product/product&path=34&product_id=28")

The navigate() method remains the same as previous tests, and the only difference is it takes in a specific product URL.

def add_to_cart(self):                
        try:
            expect(self.addtocart_button_locator).to_be_visible()
            set_test_status(self.page, "Passed", "Add To Cart button is visible")
        except Exception as ex:
            set_test_status(self.page, "Failed", "Add To Cart button is not visible")

Step 1: The add_to_cart() method uses the Playwright expect() construct to assert the element located by the addtocart_button_locator to be visible.

Step 2: The set_test_status() method defined in the utilities.py is called to inform the cloud grid of the test status if running on the cloud grid.

def buy_now(self):                
        try:
            expect(self.buynow_button_locator).to_be_visible()
            set_test_status(self.page, "Passed", "Buy Now button is visible")
        except Exception as ex:
            set_test_status(self.page, "Failed", "Buy Now button is visible")

Step 1: The buy_now() method is similar to add_to_cart() the only difference being it verifies the element located by buynow_button_locator to be visible.

Step 2: The set_test_status() method defined in the utilities.py is called to inform the cloud grid of the test status.

def checkout_product(self):                
        try:            
            # Add a product to cart first & click checkout
            self.page.goto("https://ecommerce-playground.lambdatest.io/")
            self.page.get_by_role("button", name="Shop by Category").click()
            self.page.get_by_role("link", name="MP3 Players").click()
            self.page.get_by_role("link", name="HTC Touch HD HTC Touch HD HTC Touch HD HTC Touch HD").click()
            self.page.get_by_role("button", name="Add to Cart").click()
            self.page.get_by_role("link", name="Checkout ").click()

            # Perform the test on the checkout
            coupon_code_locator = self.page.get_by_placeholder("Enter your coupon here")
            expect(coupon_code_locator).to_be_visible()
            set_test_status(self.page, "Passed", "Use Coupon Code option is visible")
        except Exception as ex:
            set_test_status(self.page, "Failed", "Use Coupon Code option is visible")

Step 1: The checkout_product() method differs from the other methods we have written so far in the sense that we first need to add a product to the cart and checkout.

Step 2: We start this method by navigating to the homepage of the test website using page.goto().

Step 3: Once on the homepage, we locate the product, and on the located product, use the Playwright click() action to add it to the cart.

Step 4: On adding to the cart, we again use the Playwright click() action to check out the product.

Step 5: On checkout, we create a locator using the get_by_placeholder() Playwright locator to locate the coupon code text box and store it in a variable coupon_code_locator.

Step 6: We then expect() the element located by coupon_code_locator to_be_visible().

Step 7: The set_test_status() method defined in the utilities.py is called to inform the cloud grid of the test status if running on the cloud grid.

Code Walkthrough (tests/test_productpage.py)

The class file productpage.py contains all of the element location and assertion code. All that remains to write in the test_productpage.py is to call the methods defined by creating objects of the class ProductPage.

We have abstracted this object creation in the fixture product_page() defined in the conftest.py discussed above.

from playwright.sync_api import expect
from utilities.utilities import set_test_status
from pages.productpage import ProductPage


def test_product_page_contains_addtocart_button(browser, product_page):
    """
    Test to verify if product page has "add to cart" button
    """    
    product_page.navigate()
    product_page.add_to_cart()
    browser.close()

Step 1: The test_product_page_contains_addtocart_button() calls the navigate() method using the product_page object to open the product page.

Step 2: Calling the add_to_cart() then executes the expect() assertion written in it.

def test_product_page_contains_buynow_button(browser, product_page):
    """
    Test to verify if product page has "buy now" button
    """    
    product_page.navigate()  
    product_page.buy_now()            
    browser.close()

Step 1: The test_product_page_contains_buynow_button() calls the navigate() method using the product_page object to open the product page.

Step 2: Calling the buy_now() then executes the expect() assertion written in it.

def test_checkout_page_contains_use_couponcode_option(browser, product_page):
    """
    Test to verify if product page has "use coupon code" option is available on checkout page
    """    
    product_page.checkout_product()            
    browser.close()

The test_checkout_page_contains_use_couponcode_option() calls directly the checkout_product() method where we execute the expect() assertion written in it.

Execution:

Now that we’ve written 8 comprehensive test cases, let’s run them first without dockerizing them to ensure they are working correctly. All the tests are saved in a file test.py, and to run them, we run the pytest -v test.py command. The -v flag is for verbose output. As we can see from the screenshot below, all test cases are running perfectly.

As the number of tests increases, we can leverage the multi-core CPU to run tests in parallel using the –numprocesses option of pytest. The performance and number of parallel processes we can spawn depend on the configuration of the host CPU.

For demo purposes, since we have 8 tests, we will set it to 3 to run 3 tests at a time. As you can see from the image below 3 different workers were spawned, and tests were run parallel depending on the availability of the workers. Parallel execution is an excellent way to speed up test execution for larger test suites.

Freezing The Python Requirements

Now that the tests are perfectly running locally, before proceeding to dockerizing the tests, we will export all the Python dependencies we installed in the virtual environment in the requirements.txt file. This is a standard process in the Python world to share dependencies. Further reading about freezing requirements is available in the official pip documentation.

Below are the contents of the generated requirements.txt file, which contains the dependency name and the version. Now, we can share this with other team members and colleagues to ensure everyone uses the same Python libraries.

attrs==22.2.0
certifi==2022.12.7
charset-normalizer==3.0.1
colorama==0.4.6
exceptiongroup==1.1.0
greenlet==2.0.1
idna==3.4
iniconfig==2.0.0
packaging==23.0
playwright==1.30.0
pluggy==1.0.0
pyee==9.0.4
pytest==7.2.1
pytest-base-url==2.0.0
pytest-playwright==0.3.0
python-dotenv==0.21.1
python-slugify==8.0.0
requests==2.28.2
text-unidecode==1.3
tomli==2.0.1
typing_extensions==4.4.0
urllib3==1.26.14

Running Playwright Docker Tests Locally

Running Playwright Docker tests locally allow you to test your Playwright scripts in a containerized environment, which can help ensure consistency and reproducibility across different environments.

In this Playwright Docker tutorial, we will go through the steps to set up and run Playwright with Docker on your local machine. We will cover how to create a Dockerfile, build a Docker image, and run a container with Playwright and Python installed. By the end of this Playwright Docker tutorial, you will have a working setup to run Playwright in a Docker container on your local machine.

Simplify your CSS to SASS conversion with our free tool! Start now!

Writing The Docker File

Now that the Playwright Docker tests are working locally, let’s move on to converting them to a Docker image. For that, we will first need a Docker file. By convention, the name of the file is Dockerfile. We will create this in the project’s root directory, i.e., outside the tests folder.

FROM mcr.microsoft.com/playwright/python:v1.30.0-focal


WORKDIR /app


COPY pages /app/pages
COPY tests /app/tests
COPY utilities /app/utilities


COPY requirements.txt /app/


RUN pip install --no-cache-dir --upgrade pip   && pip install --no-cache-dir -r requirements.txt

Walkthrough Of DockerFile

The first line tells Docker to pull the Python Playwright Docker image from Docker Hub.
We create a working directory called /app.
We copy the pages directory, which contains all the object representations of the web pages into /app/pages.
This is followed by copying the tests and the utilities directories to /app/tests and /app/utilities, respectively.
Next, we copy the requirements.txt into the Docker container.
We upgrade pip and install the dependencies from the requirements.txt file we copied in the above step.

Building The Docker Image

The next step is building the Docker image. We talked about what an image is earlier in this Playwright Docker tutorial. The command to build the image is below.

docker build -t playwright-docker

The output of the process is shown below.

docker build is the command to build images.
-t is shorthand for name and optionally a tag to the resulting image being built. We have chosen playwright-docker, and since the tag, which can also be called version, is omitted will be defaulted to the latest.
The period ‘.’ tells Docker that the Dockerfile is in the current directory.

The created image can be viewed by using the docker image ls command.

Running The Tests In Docker Container

Running the containers can simply be done using the docker run command.

docker run -it playwright-docker pytest -v

This will run the Playwright Docker tests, and here is the output.

Similar to local execution, we can also run the Playwright Docker tests in parallel in a Docker container.

We defaulted the fixture to always run on the local grid, remember?

But the code is designed to operate based on the environment variables configured in the secrets.env file. In Docker, to explicitly pass env variables, the best practice is to add all the environment variables in a key value file. This file can be passed to the docker run command when we run the container.

Just to remind you, here is what the secrets.env file looks like for us.

To run the docker container by passing it the env file, we need to leverage the — — env-file flag and the docker run command.

docker run -it — env-file secrets.env playwright-docker pytest -v

The below snapshot shows the result of the container run.

docker container ls -a command can be used to view a history of all the containers that have been run so far

Running Playwright Docker Tests On The Cloud Grid

So far, it’s clear to notice that running the Playwright Docker tests locally has some disadvantages in terms of choices of browsers and operating systems. The problems of browsers are easy to get around by installing various browsers, and the Playwright Docker image also comes pre-baked with all the browsers.

However, the issue of conducting Playwright Docker tests on different operating systems persists. How can this be resolved? One possible solution is to utilize a cloud grid provider such as LambdaTest.

Cloud testing platforms like LambdaTest offer the capability to conduct Playwright automated testing on a large scale, significantly reducing the time it takes to run these Playwright tests. With access to a browser farm of over 50 different versions of popular browsers such as Chrome, Chromium, Microsoft Edge, Mozilla Firefox, and Webkit, you can efficiently execute your Playwright Docker tests.

You can also subscribe to the LambdaTest YouTube Channel and stay updated with the latest tutorial around Selenium testing, Cypress E2E testing, Appium, and more.

To leverage LambdaTest Docker grid, we need a username and access key, which is available in the LambdaTest Profile Section once we create an account. We will now modify the secrets.env file to add the username and access key as two more environment variables named LT_USERNAME *and *LT_ACCESS_KEY.

The RUN_ON variable has also been modified to toggle the pytest fixture to initialize the connection to the cloud grid.

We do not need to rebuild the Docker image since we control the behavior externally via environment variables. Another good reason we should use environment variables to store controlling flags and data which drive the code behavior.

Let’s now rerun the Docker container with three parallel Playwright Docker tests.

docker run -it –env-file secrets.enf playwright-docker pytest -v –numprocesses 3

Below snapshot from the LambdaTest Dashboard shows the three Playwright Docker tests executing in parallel. The browser and OS we chose are also shown as small icons, along with the test results.

If we open one of the individual Playwright Docker tests, we can also get a finer view of the test run along with the steps, screenshots, video of execution, browser and OS, and other details.

Now, let’s run the same Playwright Docker tests on macOS and Safari. For that, we will need to modify the environment file secrets.env to amend the BROWSER and PLATFORM variables. Here is how the updated file now looks after the changes.

There is no need to rebuild the image; we can simply run it using the docker run command below.

docker run -it — env-file secrets.env playwright-docker pytest -v –numprocesses 3

Here is the new snapshot of the LambaTest Dashboard, again notice the browser and OS version are clearly shown as icons verifying that the Playwright Docker tests did indeed run on the configurations we made in the secrets.env file.

And to see the details of an individual test, we can open it and check for the execution details.

Docker Compose For Running Multi-Container Docker Applications

For this Playwright Docker tutorial, we have written eight tests and built a single Docker image for them. It’s easy to run the docker run command for one image. But for testing more complicated solutions with many containers and dependencies on other containers, the docker run is less than ideal. To run such multi-container applications, Docker provides an efficient tool called docker compose.

The docker compose the need to use the docker run command and can start all the containers in a single command. All we need to do is define the setup in a yaml file. The use of Docker compose in Production is always debated and unsuitable for all. This Stack Overflow discussion is nice for getting a better idea.

But for local testing, we can use it. Let’s see that in the next section of this Playwright Docker tutorial.

Writing The Docker Compose File

To leverage docker compose, we need to write a special file called docker-compose.yaml.

version: '3.9'
services:
testing:
image: playwright-docker
env_file:
- ./secrets.env

The first line version of the file contains the docker compose version. Details of which version to use can be obtained from the official Docker docs.
The next line of services is the start of the service definition, i.e., all containers this docker-compose will start.
The next line of testing is the name of the service. It can be any meaningful name that defines what the service does.
The following line image defines which image to use. If present locally, it will be used; otherwise, Docker compose will try to pull it from the Docker hub.
Instead of image, we can also use the build and give it the location of the Dockerfile, and the image will be built locally.
The next file, env_file, is where we pass the env file we define.

Execution

Let’s now run the container using the docker compose up command, and we can see all the Playwright Docker tests are still running, but the command needed to do it has been greatly simplified.

Conclusion

In conclusion, using Docker to run Playwright tests has many benefits. By building and running tests inside Docker containers, we can ensure that the Playwright Docker tests run in a consistent environment, regardless of the host machine on which they run. This can help to eliminate environment-specific bugs and make it easier to reproduce issues.

One advantage of using Docker to run Playwright tests is the ability to easily supply environment files with sensitive data, such as access keys and usernames. We could also use the env file to toggle between running Docker locally and on the cloud Docker grid. Creating separate environment files for each environment (e.g., development, staging, production) allows us to easily switch between environments without modifying the test code.

Additionally, using Docker Compose to orchestrate the test environment can simplify the process of spinning up and tearing down the necessary services for the Playwright Docker tests. By defining the services in a YAML file and running a single command, we can start all the services needed for the tests, including databases and web servers, and ensure that they are properly configured and running before running the tests.

Overall, running Playwright Docker tests can make the testing process more efficient, reliable, and secure. Whether we are running tests locally or in a continuous integration environment, Docker can help to streamline the process and ensure that the Playwright Docker tests are running in a consistent environment, with the necessary services and data available.

How to Perform Screenshot Comparison in Playwright

Jaydeep Karale — Mon, 01 Jan 2024 12:48:59 +0000

In the ever-evolving digital landscape, accessing the Internet and browsing websites has undergone significant transformations. With the rise of laptops, mobile devices, and an array of screen sizes and resolutions, how we engage with the web has evolved considerably. Furthermore, the multitude of browsers available for web browsing has added further complexity to web development and testing.

It is crucial to prioritize the consistent rendering of web content across a diverse range of devices and screen sizes. Ensuring that web pages and applications appear and function flawlessly across different viewports has become a paramount concern in web development practices.

To ensure faster and defect-free delivery, it has become increasingly important to reduce the time spent doing manual testing, be it functional or visual. Whilst functional testing helps ensure that the features work correctly, visual testing ensures that the website is rendered correctly as per the design.

Visual testing can be done manually, but it’s time-consuming, and it’s absolutely not possible to catch all changes with the naked eye. One way to reduce human errors and speed up the testing is by leveraging web automation frameworks. Playwright is one such framework that enables reliable end to end testing for web apps.

Playwright provides screenshot comparison out of the box with its TypeScript and JavaScript API, which can help visit a website, take a screenshot, and compare it with a baseline or last good known screenshot to detect any visual differences reliably.

Screenshot comparison using Playwright is a critical approach in software testing, ensuring visual consistency, improving user experience and maintaining software quality.

By incorporating Playwright screenshot comparison into the testing process we can identify and address visual issues promptly, enhancing the overall reliability and appeal of the applications and websites.

In this article, we will demonstrate how to perform screenshot comparisons in Playwright.

Why Playwright Screenshot Comparison?

Playwright screenshot comparison falls under visual testing which is a critical aspect of software quality assurance that focuses on validating the visual appearance and consistency of websites and mobile apps.

It involves comparing visual representations, such as screenshots or designs of a rendered website with the expected rendering as per product design and specification. By validating the pixel-level details, visual testing aims to identify any visual discrepancies, layout issues, or unintended changes that may impact the user experience.

Let us now see a business scenario that highlights the importance of visual testing.

An organization recently gave its website a facelift, hoping to make it look better and provide a more user-friendly experience. However, after these changes, the organization noticed a significant drop in key performance indicators like how many users were sticking around, how often people were leaving the site after viewing just one page (bounce rate), and the amount of time users spent on the site. These drops in performance raised concerns among the people in charge.

To determine what was causing these problems and make things right, the organization decided to use visual testing as a part of its quality control process. Visual testing would help them find any issues with the website’s appearance or issues that had come up due to the design changes. These problems might be why users were engaging less with the website.

To put this into context, the organization had already tried A/B testing, which showed that the new design was probably causing issues with user engagement. Visual testing was the next step in their quality control process to find the specific visual issues that made users less engaged with the website.

In a nutshell, visual testing is a vital part of the software testing process, focusing on the visual aspects that contribute to a seamless user experience. By employing visual testing techniques and leveraging the right tools, we can ensure the consistent and visually appealing delivery of their software, enhancing user satisfaction and overall quality.

Automated visual testing tools, such as Playwright, provide powerful capabilities to capture screenshots, compare pixel differences, and generate detailed reports. And talking about leveraging the right tools, let’s understand Playwright, which we will use to compare screenshots.

Need a secure hash? Try our RIPEMD160 hash calculator for quick results!

What is Playwright?

Playwright is an end-to-end web testing and browser automation framework by Microsoft. The Playwright API is available in multiple languages, such as Python, Java, .Net, JavaScript, and TypeScript, making it a strong candidate for end-to-end web testing.

At the time of writing this article on screenshot comparison in Playwright, the latest stable version of Playwright is 1.35.1, and as evident from npm trends, its popularity has been on the rise consistently since its release in 2020.

The reason for the rise in the popularity of Playwright is the easy-to-use API support for multiple languages, making adoption by developers of various tech stacks easy. This makes Playwright the perfect choice for end to end testing of web applications.

Key features of Playwright

Cross browser compatibility and multi-platform support.
Reliable testing with intelligent wait and web-specific assertions.
Complete isolation and lightning-fast execution.
Advanced tooling

How to Setup Playwright?

Before we move on to comparing screenshots using Playwright, let’s set up our development environment. Playwright is flexible and allows working with various languages such as Python, NodeJs, Java, .NET, JavaScript, and TypeScript.

For this blog, we will use the TypeScript API to perform a Playwright screenshot comparison.

Using Playwright with its Typescript API has its own advantages. In terms of installation, there are two ways in which Playwright can be installed. One of them is using the Node.js package manager like npm. The second method is using the Playwright VS Code extension.

Navigate to the extension manager on VS Code and search for Playwright. Then, install the official Playwright Test for VS Code, as shown in the image below.

Once the official extension is installed, use the Install Playwright action from the command panel to get started.

Successful installation will result in logs that look like the below image.

All the test scenarios used for the demo in this blog are compatible with Playwright version 1.32.2, Node.js version v18.15.0, and npm version 9.5.0.

Secure your data with our Whirlpool hash calculator — Fast & reliable!

How does Playwright Screenshot Comparison Work?

Under the hood, Playwright uses the pixelmatch library, a pixel-level image comparison library. When running the test for the first time, Playwright generates a reference or baseline screenshot.

This is also the reason why the first test will always fail with an error “Error: A snapshot doesn’t exist at … writing actual”. The complete error is shown in the image below.

This step generates the reference/baseline screenshot at a location that is prepared using the naming convention *test-results< testscreenshot-name-of-test-browser>*

To provide a predefined reference screenshot, we need to create a folder with the name < filename_containing_tests-snapshots > under tests and save the reference file with the name < testname-1-browser-operating_system.png >

In our case, this is how the reference screenshot would look like if we chose to provide it.

This is extremely helpful when running testing pipelines in a continuous integration setup. All well-known screenshots can be configured so that each test run compares against the expected result. This helps ensure that our pipeline can identify any deviation from the ideal results.

In the next section, we will look at how to run a screenshot comparison in Playwright.

How to Capture Screenshots Using Playwright?

To explore screenshot comparison in Playwright, we first need to understand how to capture screenshots using Playwright. The main API to capture screenshots is the page.screenshot(), shown below, is the method information:

Syntax:

page.screenshot()

Parameters

type: (string, default: png) — Decides the file extension of the saved screenshot
path: (string) — The file path to save the image. If the path is a relative path, then it is resolved relative to the current working directory. If no path is provided, the image won’t be saved to the disk
mask: (Array< Playwright Locator >) — Used to specify the locators that should be masked when the screenshot is taken. The default overlay color is pink, but it can be customized with the help of the maskColor parameter
maskColor: (string) — Used to customize the color of the masked locators.
clip: (x: number, y: number, width: number, height: number) — An object that allows clipping of the resulting screenshot

Parameters (Optional)

Shown below are some other optional configurable parameters that can be further used with the page.screenshot() method in Playwright:

animations: (string, default: allow)

When set to disabled, it stops CSS animations, CSS transitions, and web animations.

caret: (string, default: hide)

When set to hide, the screenshot will hide text caret.

omitBackground: (boolean, default: false)

It hides the default white background and allows capturing screenshots with transparency. Not applicable to jpeg images.

scale: (string, default: device)

Adjust the screenshot depending on devices with high dpi.

timeout: (number, default: device)

Adjust the screenshot depending on devices with high-dpi.

Let us now demo how we can configure its behavior to capture full-page screenshot, element screenshot, and capture the data into a buffer, which can be passed to third-party pixel comparison tools.

To demonstrate the Playwright screenshot comparison, we will be using the LambdaTest eCommerce playground.

Full-Page Screenshot Comparison Using Playwright

Let us see how to perform a full-page screenshot comparison in Playwright. We will do this by capturing a full-page screenshot of the LambdaTest eCommerce playground homepage.

Step 1: Navigate to the URL of the LambdaTest eCommerce demo website using the page.goto() method.

Step 2: Once on the page, use page.screenshot() to capture a full page screenshot by setting the parameter fullPage: true. The path parameter is used to set the name and location of the captured file.

Here is what the generated screenshot looks like.

Simplify your coding! Use our HTML escape tool for hassle-free web development.

Element Screenshot Comparison Using Playwright

The overall appearance and user experience of a website may not change entirely on a regular basis, but it’s a common occurrence for specific elements to be modified or updated. In such a case, we can combine Playwright locators and the page.screenshot() method.

For example, consider that on the demo eCommerce website, we have to capture the screenshot of the search field before and after the search operation is performed. For implementing such a test, we will need first to locate the search field and then capture the screenshot.

Step 1: To locate the search field, we use the Playwright locator getByRole(‘textbox’, {name: ‘Search For Products’}).

Step 2: On the located element, call the screenshot() method by using chaining.

The path is the file path to save the image. The screenshot type will be inferred from the file extension. If the path is a relative path, then it is resolved relative to the current working directory. If no path is provided, the image won’t be saved to the disk.

Execution

Capture Screenshot Into Buffer Using Playwright

We can also leverage third-party image comparison or post-processing tools by capturing the image data into a buffer.

We use the same example of locating the Search field, but instead of capturing a screenshot, we write the data to a variable called buffer.

Execution

Now that we have seen how to capture screenshots using Playwright let us move on to understand how visual regression testing can be performed using screenshot comparison in Playwright.

How to Perform Screenshot Comparison Using Playwright?

In this section on performing screenshot comparison using Playwright, we will use the LambdaTest eCommerce website.

Test Scenario:

Capture the baseline screenshot of the LambdaTest eCommerce homepage.
Populate the text ‘test compare screenshot’ in the homepage search input field and take a screenshot.
Expect baseline and new screenshots to show the difference in text only
.

Implementation for Generating Baseline Screenshot

test('compare screenshot', async ({ page }) => {
  await page.goto('https://ecommerce-playground.lambdatest.io/')
  await expect(page).toHaveScreenshot();
});

Call the goto() method on the page object to navigate to the demo website.
Use the expect() Playwright assertion on the page object to call toHaveScreenshot() method to capture the baseline.

Execution

We run the single test using the npx playwright test -g “compare screenshot” command on Chromium.

As expected, the test fails since we only capture the baseline screenshot for subsequent comparison.

The capture baseline screenshot is created in the directory *test-results\testscreenshot-compare-screenshot-chromium* based on the name of the test and the browser being used.

Implementation for Introducing Difference

test('compare screenshot', async ({ page }) => {
  await page.goto('https://ecommerce-playground.lambdatest.io/')
  await page.getByRole("textbox", {name : "Search For Products"}).fill('test compare screenshot')
  await expect(page).toHaveScreenshot();
});

The steps to navigate to the demo website remain the same.

On the page, we use the getByRole() Playwright locator to find the search input field. We use fill() in the located search field with ‘test compare screenshot’ arbitrary text to introduce a difference.

We then capture the screenshot using toHaveScreenshot() and the expect() assertion.

Execution

Run the test using the npx playwright test -g “compare screenshot” command on Chromium.

The command does the following things:

Show the difference in the number of pixels between the baseline and the latest screenshot.
Generate two more screenshots, one named “compare-screenshot-1-expected.png,” representing the expected output according to Playwright, and the other named “compare-screenshot-1-diff.png,” illustrating the disparity between the baseline and the captured screenshot.

Here is what the test-results folder looks like after command execution, and it contains all the screenshots, i.e., the baseline, the expected, and the difference.

Shown below is compare-screenshot-1-diff.png, which highlights the difference between the expected and actual image. It is clear that in addition to the text we introduced, our demo website also has some other font-related issues.

Here are all three images, i.e., the baseline, the screenshot captured, and the difference, all presented side-by-side to get a better idea.

Let us repeat the test, but instead of searching for an arbitrary text, this time, search for an actual product in the database.

Test Scenario:

Capture the baseline screenshot of the LambdaTest eCommerce homepage.
Search for ‘Apple’ products and take screenshots.
Expect a baseline and a new screenshot to show the difference.

Implementation for Generating Baseline Screenshot

test('compare screenshot search for apple product', async ({ page }) => {
  await page.goto('https://ecommerce-playground.lambdatest.io/')  
  await expect(page).toHaveScreenshot();
});

We will write a new test named ‘compare screenshot search for apple product.’

The page.goto() method is used to navigate the demo website under test. The toHaveScreenshot() method is used to capture the baseline screenshot.

Execution

The test can be run using the command npx playwright test -g “compare screenshot search for apple product.”

As expected, the test fails and generates the baseline screenshot under the test-results directory but in a newly created folder based on the name of the test, compare screenshot search for apple product.

Shown below is the generated baseline screenshot.

Implementation for Generating Apple Product Search Screenshot

test('compare screenshot search for apple product', async ({ page }) => {
  await page.goto('https://ecommerce-playground.lambdatest.io/')  
  await page.getByRole("textbox", {name : "Search For Products"}).fill('apple')
  await expect(page).toHaveScreenshot();
});

We use the Playwright locator to find the ‘search’ field and fill() with the search term ‘apple.’

Capture the screenshot after the search by calling the toHaveScreenshot() method on the page.

Execution

Run the test using the command npx playwright test -g “compare screenshot search for apple product”.

The output of the test run indicates the difference in the number of pixels, which is significant this time and also generated the expected and the diff images.

Here is the folder structure where all the screenshots are stored.

And the image showing the pixel difference between the baseline and the captured screenshot below shows considerable differences.

Here are all three images, i.e., the baseline, the captured, and the difference shown side-by-side.

So far, we have been using the toHaveScreenshot() method with its default configuration. But since, under the hood, it uses the PixelMatch library, the method has a few configurations available to customize the test.

Get creative with text! Try our Shuffle letters tool for unique variations.

How to Allow Acceptable Pixel Difference?

There are two ways in which we can configure an acceptable pixel difference when comparing screenshots with Playwright using the maxDiffPixelRatio and maxDiffPixels *parameters of the *toHaveScreenshot() method.

maxDiffPixelRatio is any number between 0 and 1, whereas maxDiffPixels is any number value as per the project requirement.

These parameters can be set either at each test level or can be configured as a global default inside the playwright.config.ts file within expect.

For example, to set a global default max pixel difference of 100, we would add the below line in the playwright.config.ts file.

To set a global default max pixel difference ratio of 0.5, we would add the below line in the playwright.config.ts file.

For the demo, we will repeat the scenario where we added arbitrary text in the search field of the demo website homepage.

The test result had a pixel difference of 784. Let us repeat the test to allow a pixel difference of 800 to be acceptable and rerun the test.

Test Scenario:

Capture the baseline screenshot of the LambdaTest eCommerce homepage.
Populate the text ‘test compare screenshot’ in the homepage search input field and take a screenshot but with a maxDiffPixels set to 800.

Implementation for Generating Baseline Screenshot

test('allow max pixel diff while compare screenshot', async ({ page }) => {
  await page.goto('https://ecommerce-playground.lambdatest.io/')
  await expect(page).toHaveScreenshot();
});

Execution

Run the test using npx playwright -g “allow max pixel diff while compare screenshot” command.

As expected, the test fails and generates the baseline screenshot.

Implementation for Generating Screenshot With MaxDiffPixels

test('allow max pixel diff while compare screenshot', async ({ page }) => {
  await page.goto('https://ecommerce-playground.lambdatest.io/')
  await page.getByRole("textbox", {name : "Search For Products"}).fill('test compare screenshot')
  await expect(page).toHaveScreenshot({maxDiffPixels : 800});
});

On the page, locate the search input field using Playwright locator getByRole() by supplying the role as a textbox and the name of the field, which is Search For Products. Fill the text ‘test compare screenshot’ in the located input field.

Post filling in the text, capture a screenshot of the page using the toHaveScreenshot() method, but this time setting maxDiffPixels parameter 800, which means that if the actual and expected image differ by less than 800 pixels, it is okay to pass the test.

Execution

Run the test using npx playwright -g “allow max pixel diff while compare screenshot” command.

As expected, the test passes since the pixel difference is 784, which is less than the 800 acceptable limit we set.

There are other parameters available to customize and configure the Playwright screenshot comparison. Do check the official documents for the same.

We have primarily used the Chromium browser to run our tests. This configuration is done in the playwright.config.ts file. However, based on the requirement, alternate browsers and mobile viewports can be enabled in the file, which by default are commented out.

The screenshot of the complete file is provided below, and as we can see, only Chromium is enabled, but that can be changed easily by uncommenting the required browser and viewport.

The downside of this approach is that we have to install all the required browsers locally. Installing browsers is not a big deal, but then comes the question of running the tests against different operating systems and a combination of operating systems and browsers.

To overcome this hindrance, we will leverage the cloud grid provided by LambdaTest, an AI-powered test orchestration and execution platform, and run the tests on a cloud-based scalable infrastructure. Using a cloud grid removes the dependency of installing various browser engines and setting up multiple operating system based infra to run the tests.

LambdaTest helps in Playwright screenshot comparison using its AI-powered SmartUI platform to ensure the quality and accuracy of your web application across various browsers and devices.

Catch up on the latest tutorial around the Playwright visual regression testing, automation testing, and more. Subscribe to the LambdaTest YouTube Channel for quick updates.

It provides an AI-powered Smart UI testing platform to run automated visual tests across 3000+ desktop and mobile environments. It uses AI algorithms to compare screenshots and detect differences in layout, text, graphics, or other elements. This ensures your web application looks and functions consistently on different devices and browsers.

Refer to the documentation to get started with Smart UI testing with Playwright.

Let us now see the Playwright screenshot comparison on the cloud grid provided by LambdaTest.

Efficiently manage your strings! Use our String split by delimiter tool for easy parsing.

How to Perform Playwright Screenshot Comparison on Cloud?

To power our screenshot comparison, we will be leveraging the LambdaTest Smart UI platform, where we can access various different browsers and operating systems versions. The ready availability of infra also helps perform testing at scale with minimum hassle.

To leverage the LambdaTest cloud grid, we first need to configure the username and API access key, which can be obtained from your LambdaTest Profile. To configure the username and API access key for our project to do so, we will store them in a .env file.

LT_USERNAME=<LT_USERNAME>
LT_ACCESS_KEY=<LT_ACCESS_KEY>

Remember to replace the < LT_USERNAME > and < LT_ACCESS_KEY > with proper credentials when running the tests.

Next, we need to set up the playwright.config.ts to be able to leverage the infrastructure on the cloud. For this demo, we will be using Windows 11 and Chrome (latest).

import { defineConfig, devices } from '@playwright/test';


export default defineConfig({  
  testDir: './tests',  
  fullyParallel: true,  
  forbidOnly: !!process.env.CI,  
  retries: process.env.CI ? 2 : 0,  
  workers: process.env.CI ? 1 : undefined,  
  reporter: 'html',  
  use: {    
    trace: 'on-first-retry',
  },


  /* Configure projects for major browsers */
  projects: [
    {
      name: "chrome:latest:Windows 11@lambdatest",    
    },


    /* Comment the above lines & Uncomment the below lines to run on local */
    // {
    //   name: 'chromium',
    //   use: { ...devices['Desktop Chrome'] },
    // },  
  ],
});

To connect to the LambdaTest cloud grid info we have amended the projects array to add the Windows 11 and Chrome setup and added the keyword ‘@lambdatest’.

If we want to run the tests locally, we will simply comment the LambdaTest line and uncomment the Chromium browser or add any other browser on which you intend to run the tests.

The next file needed to leverage the LambdaTest cloud grid, which we will look at, is the lambdatest-setup.ts. Here is how the complete file looks like.

import * as base from "@playwright/test";
import path from "path";
import { chromium } from "@playwright/test"
import dotenv from 'dotenv';
dotenv.config();


// LambdaTest capabilities
const capabilities = {
  browserName: "Chrome", // Browsers allowed: `Chrome`, `MicrosoftEdge`, `pw-chromium`, `pw-firefox` and `pw-webkit`
  browserVersion: "latest",
  "LT:Options": {
    platform: "Windows 11",
    build: "Playwright SmartUI Build",
    name: "Playwright Compare Screenshots",
    user: process.env.LT_USERNAME,
    accessKey: process.env.LT_ACCESS_KEY,    
    network: true,
    video: true,
    console: true,    
    geoLocation: "" ,// country code can be fetched from https://www.lambdatest.com/capabilities-generator/
    "smartUIProjectName": "Playwright-SmartUI-Project",
  },
};


// Patching the capabilities dynamically according to the project name.
const modifyCapabilities = (configName, testName) => {
  let config = configName.split("@lambdatest")[0];
  let [browserName, browserVersion, platform] = config.split(":");
  capabilities.browserName = browserName
    ? browserName
    : capabilities.browserName;
  capabilities.browserVersion = browserVersion
    ? browserVersion
    : capabilities.browserVersion;
  capabilities["LT:Options"]["platform"] = platform
    ? platform
    : capabilities["LT:Options"]["platform"];
  capabilities["LT:Options"]["name"] = testName;
};


const getErrorMessage = (obj, keys) =>
  keys.reduce(
    (obj, key) => (typeof obj == "object" ? obj[key] : undefined),
    obj
  );


const test = base.test.extend({
  page: async ({ page, playwright }, use, testInfo) => {  
    // Configure LambdaTest platform for cross-browser testing
    let fileName = testInfo.file.split(path.sep).pop();
    if (testInfo.project.name.match(/lambdatest/)) {
      modifyCapabilities(
        testInfo.project.name,
        `${testInfo.title} - ${fileName}`
      );
      const browser = await chromium.connect({
        wsEndpoint: `wss://cdp.lambdatest.com/playwright?capabilities=${encodeURIComponent(
          JSON.stringify(capabilities)
        )}`,
      });


      const ltPage = await browser.newPage(testInfo.project.use);
      await use(ltPage);

      await ltPage.close();
      await browser.close();
    } else {
      // Run tests in local in case of local config provided
      await use(page);
    }
  },
});


export default test;

Code Walkthrough

Let us now understand the individual components of the file in detail one by one.

Step 1: Understand Imports

The imports are standard apart from the dotenv package, which we use to read the USERNAME and ACCESS_KEY from the.env file.

Step 2: Understanding the JSON capabilities

The capabilities JSON object is where we configure the behavior of the LambdaTest cloud grid.

Set the default browser and version to be used on the cloud grid.

platform: Used to set the default operating system.
build: Specifies the name of the current build under which all tests will be grouped.
name: Specifies the test name.

The USERNAME and ACCESS_KEY required to connect to the LambdaTest cloud grid are read from environment values.

network: Used to configure if the cloud grid captures network logs.
video: Used to configure if the cloud grid captures video of test execution
console: Used to configure if the cloud grid captures console logs

geoLocation is used to configure the geographic location used to run the test.

smartUIProjectName is the name of the Smart UI project on the LambdaTest dashboard.

Here is the complete JSON object for reference.

// LambdaTest capabilities
const capabilities = {
  browserName: "Chrome", // Browsers allowed: `Chrome`, `MicrosoftEdge`, `pw-chromium`, `pw-firefox` and `pw-webkit`
  browserVersion: "latest",
  "LT:Options": {
    platform: "Windows 11",
    build: "Playwright SmartUI Build",
    name: "Playwright Compare Screenshots",
    user: process.env.LT_USERNAME,
    accessKey: process.env.LT_ACCESS_KEY,    
    network: true,
    video: true,
    console: true,    
    geoLocation: "" ,// country code can be fetched from https://www.lambdatest.com/capabilities-generator/
    smartUIProjectName: "Playwright-SmartUI-Screenshot-Compare",
  },
};

Step 3: Overriding the *@playwright/test *method to facilitate LambdaTest cloud grid connection

The next part of the lambdatest-setup.ts file is to override the @playwright/test method to ensure that we can run the tests either on the cloud grid or locally.

We check the playwright.config.ts file to see if the project’s array contains the keyword lambdatest. If it does perform a connection using the capabilities object to LambdaTest Smart UI and initialize the page object using cloud infrastructure.

For connecting to the cloud grid infrastructure, a WebSocket connection using the CDP (Chrome DevTools Protocol) endpoint is used. A CDP endpoint refers to the URL or address that allows communication between a client (such as a web browser) and the Chrome DevTools Protocol server.

The Chrome DevTools Protocol is a debugging protocol used by various browser developer tools to interact with and control a web browser instance programmatically.

To establish a WebSocket connection with the Chrome DevTools Protocol server, you need to specify the CDP endpoint. The endpoint typically follows the format: wss://{host}:{port}/devtools/{pageTarget}. More details below:

{host}: Refers to the host or IP address where the Chrome DevTools Protocol server is running. It can be a local or remote address.
{port}: Represents the port number used by the Chrome DevTools Protocol server for WebSocket connections. The default port is usually 9222.
{pageTarget}: Specifies the target page or tab in the web browser for which you want to establish a DevTools Protocol connection. This can be a unique identifier or a specific page URL.

By connecting to the CDP endpoint via a WebSocket, you can send commands, receive responses, and listen for various events related to the web browser’s behavior, network activity, debugging, and more. This enables developers and tools to automate tasks, analyze performance, debug code, and gather information about the web page or application being inspected.

If the keyword is not detected, a local instance of the Playwright page is returned using the browser configured in playwright.config.ts

This completes the setup required to leverage the LambdaTest Smart UI. Now, we’ll craft the test scenario, closely resembling the one employed previously during our local screenshot comparison testing.

Test Scenario

Navigate to the LambdaTest demo eCommerce website homepage and capture the baseline screenshot.
Navigate to the LambdaTest demo eCommerce website homepage, search for Apple products, and take another screenshot.

Need to convert text quickly? Use our Text lowercase tool for instant results.

Implementation

import test from "../lambdatest-setup";
est('capture full page screenshot using SMARTUI', async ({ page }) => {
  await page.goto('https://ecommerce-playground.lambdatest.io/')
  await page.evaluate((_) => {},
    'lambdatest_action: {"action":"smartui.takeScreenshot","arguments":{"fullPage":true,"screenshotName":"homepage-without-search.png"}}')
  await page.evaluate(_ => {}, 'lambdatest_action: {"action":"setTestStatus","arguments":{"status":"passed","remark":"Screenshot captured"}}')
});

Let us see a step-by-step walkthrough of the code.

Step 1: The test method being used now is from lambdatest-setup.ts instead of @playwright/test.

Step 2: Navigate to the demo website homepage using the page.goto() method.

Step 3: The evaluate() function requests the SmartUI to trigger the takeScreenshot function. Additional arguments are used to dictate the function to take a fullPage screenshot and also specify the screenshotName.

Step 4: Finally, we run evaluate() again, this time to mark the test successful, saying the screenshot has been captured.

Execution

Run the test using npx playwright test -g “capture full page screenshot using SMARTUI”.

The build gets passed successfully, which can be seen on the LambdaTest Web Automation Dashboard.

On clicking the name of the test, we can also see detailed execution logs.

The LambdaTest Smart UI page also reflects the details under the name we configured in the capabilities object in lambdatest-setup.ts.

When the test passes, the screenshot captured is treated as a baseline for future comparisons.

If the captured screenshot fails for some reason, such as a timeout network issue or any other reason, a screenshot of a subsequent run can be manually marked as the baseline.

This is what the baseline screen looks like.

Now that a baseline is established, let us amend the test to search for Apple products.

test('capture full page screenshot using SMARTUI', async ({ page }) => {
  await page.goto('https://ecommerce-playground.lambdatest.io/')
  await page.getByRole("textbox", {name : "Search For Products"}).fill('apple')
  await page.evaluate((_) => {},
    'lambdatest_action: {"action":"smartui.takeScreenshot","arguments":{"fullPage":true,"screenshotName":"homepage-without-search.png"}}')
  await page.evaluate(_ => {}, 'lambdatest_action: {"action":"setTestStatus","arguments":{"status":"passed","remark":"Screenshot captured"}}')
});

The modified test code has one line of change, i.e., locating the search field and filling in the text apple.

We run the test again using the command npx playwright test -g “capture full page screenshot using SMARTUI”.

Smart UI has found issues as expected since we introduced it for demo purposes by searching Apple products.

The highlighted section shows the thresholds and the % mismatch. It also has the option to approve/reject the changes.

The Smart UI project is also configurable from the LambdaTest Smart UI Dashboard.

Some important settings have been highlighted & explained below

The addition of an Approver allows the configuration of test approvers.
Project Name can be configured in SmartUI and within the capabilities of JSON in the lambdatest-setup.ts file.
The Pixel Threshold establishes the granularity at which pixel blocks are generated.
The Custom Mis-Match % Acceptance Rate allows the configuration of pixel-to-pixel acceptance below the specified percentage for automatic approval and rejection.

Conclusion

In summary, Playwright offers a robust solution for screenshot comparison, helping teams effectively manage visual regression and maintain the visual consistency of their apps and websites.

With Playwright’s robust API and wide browser compatibility, developers and testers can effortlessly automate browser interactions and capture screenshots. By utilizing Playwright’s screenshot comparison features, teams can create baseline screenshots and compare them to test runs or production updates later.

This enables the identification of visual regressions stemming from code modifications, layout discrepancies, or unexpected rendering differences across various browsers and devices.

We have also seen how we can leverage the Smart UI platform of the LambdaTest cloud grid to compare screenshots. Using a cloud grid allows us to perform screenshot comparisons on various browsers and versions. This helps make the test suite more robust and scalable.

How To Use Playwright Inspector For Debugging

Jaydeep Karale — Mon, 04 Dec 2023 10:43:23 +0000

Debugging is the process of identifying and resolving errors or bugs in software. In web automation testing, debugging plays a crucial role in ensuring the reliability and accuracy of automated tests. Additionally, it enables the validation of functionality by applying dynamic values.

According to the Systems Sciences Institute at IBM, the expense of addressing an error discovered after product release was four to five times higher than identifying it during the design phase and even up to 100 times greater than one detected during the maintenance phase.

The debugging process typically involves noting the error, identifying the error location based on expertise, setting debugger breakpoints, analyzing the code step-by-step at runtime, finding the exact location of the issue, fixing the problematic code line, and validating the code to ensure a successful error fix.

Choosing an automation testing framework with effective and robust debugging tooling is key to writing and maintaining a high-quality test automation suite. Playwright, an open-source framework released by Microsoft in 2020, is quickly becoming popular for cross-browser testing.

Playwright can work with the browser at the API level and provides robust tooling with the built-in Playwright Inspector.Playwright Inspector simplifies creating automation scripts by providing auto code generation capabilities. With Playwright Inspector, developers, and testers can interactively explore web applications, inspect elements, and perform actions such as clicking buttons, filling forms, and navigating through pages.

Playwright Inspector lets you view the DOM structure of a webpage, inspect CSS styles, and interact with web elements using the Playwright API. It allows stepping through tests, live locators editing, picking locators, and seeing actionability logs.

One of the standout features of Playwright Inspector is its ability to record and replay user interactions. This functionality allows developers to reproduce bugs and see how their web applications behave in different scenarios. This information can be used to debug and fix issues more effectively.

In this blog, we will explore Playwright Inspector, a graphical user interface (GUI) tool that allows us to inspect and debug Playwright scripts interactively in great detail.

So, let’s get started!

What is Playwright?

Playwright, developed by Microsoft, is an open-source end-to-end web testing and browser automation framework. It offers excellent cross-browser compatibility and user-friendly features, making it an ideal option for automation and quality assurance purposes.

It is flexible and supports multiple languages such as Python, TypeScript, JavaScript, Java, and C#. It uses a single automation API which makes it reliable and fast and produces consistent results while performing cross browser testing.

Playwright provides a robust and powerful set of testing features that can be used to simulate user interactions with the web application. With Playwright, we can test complex scenarios such as login flows, file uploads, and other interactions that are difficult to test with other testing frameworks.

It offers a wide range of built-in and custom locators to help developers easily and efficiently locate elements on web pages. Locators can identify elements based on their attributes, text content, position on the page, and more. Playwright locators help to reliably identify elements on DOM and thus build resilient and robust test suites.

If you are preparing for an interview you can learn more through Playwright interview questions.

A quick summary of features of Playwright

Multi-Browser Support

Playwright supports cross-browser automation, which includes Chrome, Firefox, Safari, and Microsoft Edge. This makes it easier for developers to write tests that can run on different browsers.

Advanced Browser Automation

Playwright provides a rich set of APIs for automating browser interactions such as page navigation, filling out forms, clicking buttons, and much more.

Powerful Debugging Capabilities

Playwright allows developers to easily debug their tests with tools like the built-in debugger and visual logs, making it easier to diagnose issues during test development.

Easy to Use and Flexible

Playwright is designed to be easy to use and flexible, with a simple API that allows developers to write tests in their preferred programming languages, such as JavaScript, TypeScript, or Python.

Scalability

Playwright allows developers to run tests in parallel across multiple browsers and devices, making it easy to scale up test suites to handle large-scale testing scenarios.

Auto-wait and Retry

Playwright’s auto-wait and retry features make it easier to handle flaky tests by automatically waiting for page elements to become available and retrying failed test steps, improving the reliability of tests.

You can also subscribe to the LambdaTest YouTube Channel and stay updated with the latest tutorial around Selenium testing, Playwright browser testing, Appium, and more.

Ensure compatibility across platforms with cross browser device testing.

What is a Playwright Inspector?

Playwright Inspector is a GUI-based tool that helps developers & testers record scripts and debug Playwright tests. It helps generate boilerplate code, which can be a good starting point for building code. This helps developers & QA teams save time which may be required when writing everything from scratch.

Developers can use the saved time to understand the code base and then confidently make relevant changes as and when needed to improve the test suites.

The Playwright Inspector can be started using the codegen command followed by the website URL to inspect. The URL is optional and can also be added when the browser starts.

playwright codegen https://ecommerce-playground.lambdatest.io/

On running the command by specifying the URL:

Playwright Inspector will open the mentioned website in Chromium by default
Initiate the Playwright Inspector tool, record actions up to the current point, and showcase the corresponding code snippet.
Our action at this point has been to only navigate to the LambdaTest eCommerce Playground URL code for that action to be present.
Playwright, by default, will display code using the Library API to handle the creation of the browser, context, and page explicitly.
On the created page, the goto() method is called with the URL specified on the command line.

Run Automated Playwright Tests Online.Try LambdaTest Now!

Features of Playwright Inspector

Generating code first and subsequently refining it is a practical and time-saving approach. One of the USPs of Playwright is the Playwright Inspector tool, which helps developers record scripts and debug Playwright tests using breakpoints. Here are some of the key features of the Playwright Inspector tool:

Boilerplate Code

With its intuitive interface and powerful features, Playwright Inspector makes it easy for developers to find and fix bugs in their code. One of the standout features of Playwright Inspector is its ability to record and replay user interactions.

Playwright Inspector records user actions and helps find elements by using the Playwright locators and selecting the best locator for the element. This functionality allows developers to reproduce bugs and see how their web applications behave in different scenarios.

Network trace analysis

This feature enables tracking the performance of web applications and identifies any bottlenecks that may be affecting user experience. This information can then be used to optimize code to improve the performance of web applications.

As Playwright supports multiple languages, you can choose your preferred language using the drop-down at the top right, as seen in the image below.

The Playwright Inspector tool will always use Chromium by default, but that behavior can be overridden using the — -browser flag on the command line. As Playwright supports WebKit, Chromium, and Firefox, the other option we can use with — -browser is WebKit.

Ensure your website’s compatibility across devices. Test your website on different devices now!

playwright codegen https://ecommerce-playground.lambdatest.io/ --browser firefox

Now we have seen some of the core features of Playwright Inspector. In the next section, we will learn more about its advantages and shortcomings.

Optimize your app’s performance on various gadgets with device testing.

Advantages of Playwright Inspector

The Playwright Inspector tool offers several advantages. Let’s look at some key benefits of the Playwright Inspector:

Easy Debugging

Playwright Inspector simplifies the process of debugging Playwright scripts by providing a visual interface that allows developers to inspect the page, modify its state, and identify the cause of issues quickly.

Record and Replay

Playwright Inspector offers a record and replay feature that allows testers and QA teams to record user actions on the page and replay them for debugging purposes.

This feature can help identify issues that may only occur during specific user interactions.

Intuitive Interface

Playwright Inspector has an intuitive and user-friendly interface. It is easy to navigate and use, even for testers and QA teams new to Playwright.

Robust Logging

Playwright Inspector offers robust logging capabilities that allow testers and QA teams to trace the execution flow of their test script.

This helps quickly identify issues and make fixes, thereby improving trust in the code and application itself.

Breakpoints

The Playwright Inspector tool allows testers and QA teams to set breakpoints in their test script, pause test execution at specific points and investigate the page’s state.

This provides greater control and visibility over the testing process. It helps improve the overall efficiency and effectiveness of the testing process

Cross-Browser Support

Playwright Inspector supports multiple Chromium-based browsers, including Chrome, Edge, and Firefox, allowing developers to test and debug their applications across various platforms.

Overall, the Playwright Inspector tool is valuable for developers looking to debug their Playwright scripts effectively. Its intuitive interface, record and replay capabilities, and robust logging features make it a powerful tool for identifying and resolving issues quickly.

Shortcomings of Playwright Inspector

Although Playwright Inspector is a powerful tool for debugging test scripts while performing Playwright automation, it does have a few limitations and potential drawbacks:

Failure To Record Mouse Scroll

Playwright Inspector does not record mouse scroll events. Hence, for tests that require us to scroll down to elements to prepare locators, a manual task is involved in writing the mouse scroll event. The video/gif shows the user action of scrolling down on a page and Playwright Inspector, which makes no record of the scroll

The image below shows a sample test dynamic element, which requires the mouse.wheel() to be added manually.

Master iOS app automation! Learn how to use Appium on iOS real device with our guide.

Manual Coding For Testing Lazy-Loaded Elements

Locating lazy-loaded elements requires scrolling them. Since the scroll events are not recorded by the Playwright Inspector, it becomes challenging to test lazy loading elements as supporting code needs to be written manually.

Overhead & Resource Consumption

Since the Playwright Inspector launches Chromium in non-headless mode, it consumes additional resources (i.e., bump-up in CPU consumption, increased RAM utilization), which can impact the performance tests being executed. This can lead to slower test execution, give an impression of a slow-running application, and increase the likelihood of false positives and negatives.

The overhead depends on several factors, such as the machine’s capacity where tests are run in terms of Operating System, RAM, and CPU cores.

Limited Customization

The Playwright Inspector tool has limited customization options. While it does allow modifying the page’s state, it does not provide much flexibility in terms of adding custom code or changing the test script within the GUI.

Despite these limitations, Playwright Inspector remains a valuable tool for debugging Playwright scripts and can significantly reduce the time and effort required to identify and fix issues during the development and Playwright automated testing process.

Streamline your iOS app’s functionality with ios device testing online.

How to generate tests using Playwright Inspector?

Playwright is language agnostic, and its API is available in various languages like Java, Python, .Net, JavaScript, and TypeScript. For this blog, we will be using the TypeScript API of Playwright. Before we start writing tests, let’s quickly understand the installation process for using Playwright with TypeScript.

How to install Playwright using TypeScript?

Combining Playwright with TypeScript offers a powerful and efficient approach to web automation and testing. TypeScript, a typed superset of JavaScript, enhances the development experience by providing type safety, enhanced IDE support, modern JavaScript features, and improved code readability.

When used with Playwright, a versatile browser automation tool, TypeScript unleashes its full potential, enabling developers to build robust, maintainable, and scalable automation scripts. In terms of installation, there are two ways in which Playwright can be installed.

Using the Node.js package manager like npm.
Using the Playwright VSCode extension.

Using the Playwright VSCode extension is much easier and more user-friendly. We simply need to navigate to the extension manager and search for Playwright. Then install the official Playwright Test for VSCode, as shown in the image below.

Once the official extension is installed, use the ‘Install Playwright’ action from the command panel to get started.

A successful installation will result in logs that look like the below image.

The installation will also result in a proper directory structure that resembles the image shown. The tests folder will contain a sample test, and all new tests should be added to this folder only. The package.json will contain the Playwright version, and the demo test app is also included in the test-examples folder.

The playwright.config.ts file, generated during installation, holds crucial configuration information, including the test lookup folder, making it an essential component of the setup.

The below line implies that Playwright will look for tests to be executed under the folder tests at the project’s root.

export default defineConfig({
  testDir: './tests',

The reporter to be used to generate reports after tests are run.

reporter: 'html',

List of browsers and device viewports to run the tests on. We will be later configuring this file to debug tests on mobile viewports.

An optional github/workflow has been included because we chose to do so when installing Playwright. This step is optional and is only necessary if CI/CD integration needs to be done.

Achieve flawless user experience. Start cross device testing with LambdaTest today!

How to write a Playwright TypeScript test?

Now that the installation is completed let’s move on to writing the tests. We will use the LambdaTest eCommerce Playground website for writing the tests for this blog.

Test Scenario 1: Assert the ‘Continue’ link exists for new customer registration and is visible

Step 1

Navigate to the website under test. This will open up the Playwright Inspector and Chromium, the default browser, and record the first action, navigating to the My Account page as specified by the URL.

npx playwright codegen 
https://ecommerce-playground.lambdatest.io/index.php?route=account/login

Step 2

Stop the recording by clicking the ‘Record’ button.

Step 3

The ‘Pick Locator’ will be visible immediately, and the ‘Record’ button will be grayed out, indicating recording is stopped.

Step 4

We can either start typing in the text form to manually locate elements or click on ‘Pick Locator’ to automatically let the Playwright Inspector choose the best locator for the particular element. Locators are central to Playwright and its ability to find elements on the DOM.

Playwright provides seven built-in locators, which are recommended and can suffice most scenarios. If there remains a need to work with CSS or XPath, the page.locator() can be used to build custom locators. Playwright locators play a key part in making auto-wait and retry possible.

In the below image, we see how we can locate all the links using the getByRole() Playwright locator.

Step 5

To avoid manual selection, we can click on the ‘Pick Locator’, which will enable automatic locator selection. The ‘Pick Locator’ will also turn blue, indicating automatic locator selection is on.

Step 6

Once the automatic locator selection is on, we need to act on the element we want to locate. We want to locate the ‘Continue’ button, so we click on it. The Playwright Inspector will automatically choose the ideal locator for the element, in this case, ‘getByRole()’, to consistently locate the element under test.

This locator is optimized for identifying elements based on their roles, aligning with how users and assistive technology perceive the page. It helps determine whether an element is a button, checkbox, or other relevant components.

Role locators encompass a wide range of elements, such as buttons, checkboxes, links, lists, tables, and more. These locators adhere to the W3C specifications for ARIA roles, ARIA attributes, and accessible names, ensuring compatibility with accessibility standards.

This generated Playwright locator can be copied using the ‘Copy’ button and added to the test.

Playwright Inspector assigns a default name to the generated test. To align with the specific scenario being tested, it is necessary to rename it appropriately and assign a more fitting name. Lastly, on the located element, we use the expect() Playwright assertion and the toBeVisible() method to ensure the element is visible on the page under test.

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


test('new customer registration link to be visible', async ({ page }) =&gt; {
  await page.goto('https://ecommerce-playground.lambdatest.io/index.php?route=account/login');
  await expect(page.getByRole('link', { name: 'Continue' })).toBeVisible()
});

Test Scenario 2: Assert ‘E-mail’ and ‘Password’ fields exist on the customer login form and are visible

In the upcoming scenario, our focus will be on generating tests to ensure that the customer login form includes a designated input field for entering both email and password.

The steps for initiating the Playwright Inspector tool, pausing the recording, and enabling automatic locator selection remain consistent with the previous test.

On clicking the ‘E-Mail Address’ field, the getByPlaceholder(‘E-mail Address’) locator is prompted by the Playwright Inspector tool.

Similarly, on clicking the ‘Password’ field, the getByPlaceholder(‘Password’) locator is prompted by the Playwright Inspector tool.

The getByPlaceholder() Playwright locator leverages the presence of the placeholder attribute in form input fields, providing a useful hint to users regarding the expected input value. This locator is particularly advantageous in scenarios involving form fields, especially when labels are absent, but placeholder texts are available.

On the locators, we use the Playwright expect() and toBeVisible() assertion to ensure that the locator points to an element visible on the DOM.

test('email password to be visible', async ({ page }) =&gt; {
  await page.goto('https://ecommerce-playground.lambdatest.io/index.php?route=account/login');
  await expect(page.getByPlaceholder('Password')).toBeVisible()
  await expect(page.getByPlaceholder('E-Mail Address')).toBeVisible()
});

Test Scenario 3: Assert ‘Forgotten Password’ link exists on Returning Customer form and is visible

The next scenario we will generate tests for is to make sure the customer login form has the ‘Forgotten Password’ link in case a returning customer

The steps to start the Playwright Inspector tool, pause the recording and enable automatic locator selection remain unchanged.

On pausing the record and clicking the ‘Forgotten Password’ link, we can notice the prompted locator is again getByRole(‘link’, {name: ‘Forgotten Password’, exact: True’}).

The exact: True filter is applied by Playwright Inspector to the getByRole() locator as the ‘Forgotten Password’ link is present twice on the page. The image below shows that if we remove exact: True, the locator matches two elements with the HTML link role and name matching the text ‘Forgotten Password’. The second ‘Forgotten Password’ has a space after the ‘Password’ filter helps eliminate it from the selection.

To prevent such behavior and ensure precise element matching, the Playwright Inspector intelligently includes an additional parameter in the generated locator. This ensures that only the intended element is matched, eliminating ambiguity or unintended matches.

We then copy the generated test code and locator and give it a proper name. We then use the expect() and toBeVisible() Playwright assertion to ensure the element under test is visible on the DOM.

test('forgotten password to be visible', async ({ page }) =&gt; {
  await page.goto('https://ecommerce-playground.lambdatest.io/index.php?route=account/login');
  await expect(page.getByRole('link', { name: 'Forgotten Password', exact: true })).toBeVisible()
});

Let’s now execute these three tests before we move on to writing the fourth and final test of this blog.

Execution

Running tests is possible using the VSCode extension or nodejs CLI (command line). The simplest command is the npx playwright D:\Python\pwinspectorjs\test. This command searches in the TestDir (default: ./tests) for all files with the extensions .spec.ts(js). Tests are run against all browsers.

We can also generate a detailed text execution HTML report using the npx playwright show-report command. The output of which looks like below.

Test Scenario 4: Assert Add Quantity & Product Image Gallery

Hovering over any product shows a pop-up menu that contains options like ‘add to car’, ‘add to wish list’, ‘quick view’, and ‘compare product’. On clicking the ‘quick view’ button, a subsequent modal opens up that has the product info along with an input field to increase quantity, add to cart, and buy now buttons.

modal opens up that has the product info along with an input field to increase quantity, add to cart, and buy now buttons.

Here is the overall scenario:

Click the ‘+’ icon 5 times and verify if the quantity is updated to 6.
Product image gallery to have a total of 5 images.

The URL of the product page is

*https://ecommerce-playground.lambdatest.io/index.php?route=product/category&path=57*

Open the Playwright Inspector tool and pass the URL as shown below:

npx playwright codegen
https://ecommerce-playground.lambdatest.io/index.php?route=product/category&path=57

The opened chromium and Playwright Inspector resemble a blank canvas where we are free to perform actions, and the recording will start.

After entering the URL and pressing enter, the action is recorded, as seen in the image below.

The product images on the test website are lazy-loaded, i.e., we have to scroll down to load them and be able to locate them.

⚠️The downside of the Playwright Inspector, however, is that it cannot record the scroll event. So, later in the generated code, we will have to add the mouse scroll manually.

For now, let’s continue locating the product and pop-up menu. The pop-up menu is available only when we hover over the product. The Playwright Inspector doesn’t record this hover action as well.

So, another issue that we need to handle manually. But it gives us the locator of the product, which is enough. On this locator, we can call the Playwright hover() method.

Next, we locate ‘Quick View’ from the pop-up menu and click on it.

On the subsequent modal that opens, we can locate the ‘+’ element, which increases the quantity and can be clicked to increase the quantity. Here we can either perform the click action multiple times using the Playwright click() method or supply the {clickCount: 5} parameter to the click() method to increase it to 6 directly.

The last one is locating the image group, which cannot be directly reached. We have to use Playwright locator chaining first to get the image gallery element and then all the links with the name HTC Touch HD. We can see there are a total of 5 images, so the locator should match 5 elements. This is exactly the assertion we will verify.

The final boilerplate code generated by Playwright Inspector looks like below. While it’s not perfect and lacks the hover() on the product and the mouse scroll, it’s a good starting point. Even with these shortcomings, Playwright Inspector did a good job of providing complex locators, and in the case of the image gallery, even was able to generate chained Playwright locators.

test('dynamic element’, async ({ page }) => {
  await page.goto('https://ecommerce-playground.lambdatest.io/index.php?route=product/category&path=57');
  await page.mouse.wheel(0, 50)
  await page.getByRole('link', { name: 'HTC Touch HD HTC Touch HD HTC Touch HD HTC Touch HD' }).hover()
  await page.locator('button:nth-child(3)').first().click();
// the { clickCount:5 } has been added manually to simulate adding 5 items as once
  await page.getByRole('button', { name: 'Increase quantity' }).click({clickCount: 5});


// the following two lines which perform the expect test assertion have been added manually
  await expect(page.getByRole("spinbutton", { name :'Qty' })).toHaveValue('6')
  await expect(page.locator('#image-gallery-212946').getByRole('link', { name: 'HTC Touch HD' })).toHaveCount(5)
await page.pause()
});

Code Walkthrough

Step 1

We first navigate to the product page URL.

Step 2

The product images are lazy loaded, so we simulate the mouse scroll, which the Playwright Inspector does not capture.

Step 3

Next, we hover() over the product image to make the pop-up menu visible.

Step 4

On the pop-up menu, ‘Quick View’ is the 3rd element located by the tool.

Step 5

The ‘+’, which increases the quantity, is a button. We locate and click on it and amend the click() method to simulate 5 clicks by adding the {clickCount :5 } argument

Step 6

After this, we locate the input element where the quantity is displayed and use the expect() assertion to make sure it has the value 6

Step 7

Lastly, we use the expect() assertion of the product image gallery locator and assert it to have matched 5 elements for the 5 images seen.

Step 8

The await page.pause() method supports the pause of debugging execution at this point.

Execution

Now, let’s execute the single test. This can be done by using the -g flag and giving the name of the single test we want to run.

npx playwright test -g “dynamic element”

npx playwright show-report allows viewing the HTML report providing insights into the test run such as the number of tests run, passed, failed, and flaky tests. The individual tests also show browsers against which it was run. Clicking on individual tests also shows details about steps and actionability logs.

The below image shows the overview of the generated HTML report.

We can click on the individual test and then view the actionability logs in each step, as shown in the image below.

The Playwright Inspector is not only capable of recording user actions to generate scripts and tests but can also be used to debug tests.

How to debug tests using Playwright Inspector?

To run the Playwright Inspector in debug mode, we need to use the — — debug *flag. By default, this will run all the tests one by one based on the browsers configured in the *playwright.config.ts file and open the inspector and a browser window for each test.

We will be reusing the same test suite we wrote in the blog to understand debugging using Playwright Inspector. Since we have only configured one browser, Chromium, in our config file playwright.config.ts, only that will be used for debugging run.

Starting the execution of the tests in debug mode.

npx playwright test --debug

The Playwright Inspector will start in debug mode, and the top menu will reveal options to resume (F8), Step over (F19) tests, which allow step-by-step debugging, are now activated.

The actionability logs also start showing at the console, indicating the progress of the test.

The Chromium browser will always launch in headless mode with no default timeout. No action will be performed if we do not press the Resume or Step over button.

The upper half of the Playwright Inspector shows the code under test, and the lower half shows the actionability log. This can help us understand what happened during our test and what Playwright did or tried to do. The log informs if the element was visible, enabled, and stable, if the locator resolved to an element, scrolled into view, and so much more. If actionability can’t be reached, it will show the action in the Pending state.

Live Editing Playwright Locators

When a running test is paused, we can also experiment with various locators to find elements. ‘Pick Locator’ needs to be enabled, and then on the text field next to it, we can use the built-in or custom locators to find elements.

The example image below shows the use of the getByRole(“link”) locator to find all the links on the page. This helps us debug the existing locators and fine-tune the auto-generated locator.

Debug a Test From a Specific Breakpoint

Sometimes, we don’t want to step through the entire test execution and speed up the debugging process by stopping after certain actions or several lines have elapsed. By default, when running the tests in debug mode, the control execution stops at each step on pressing the step over button and only runs the entire test if we press the resume button.

To override this behavior, we can add await page.pause() call in our tests. When we do this and start test execution, the Playwright inspector will only run the test until the point it encounters await page.pause(). As soon as it finds the await page.pause(), the execution is halted until we press the Resume button on the page overlay or there is a call to playwright.resume().

To demonstrate this, let’s add await page.pause() to the test(’email password to be visible’, async ({ page }) after the Password email assertion. Shown below is the modified implementation:

test('email password to be visible', async ({ page }) => {
  await page.goto('https://ecommerce-playground.lambdatest.io/index.php?route=account/login');  
  await expect(page.getByPlaceholder('Password')).toBeVisible()
  await page.pause()
  await expect(page.getByPlaceholder('E-Mail Address')).toBeVisible()
});

Let’s now run a single test in debug mode

npx playwright test  -g “email password to be visible”  -- debug

And as expected the test control execution has stopped at the first instance of await page.pause().

Debug Tests on Mobile Viewport

The TypeScript and JavaScript API of Playwright Inspector supports debugging tests on all or a single browser or even on mobile viewports. The configuration for setting the allowed browsers and mobile viewports needs to be done in the playwright.config.ts file.

Consider, for example, that we want to debug the tests written in file example.spec.ts only on Mobile Safari.

Modify the playwright.config.ts to include the Mobile Safari viewport and the device as iPhone 12. The browsers and device settings are done under the projects list, as shown below.

Shown below is the debug output:

And if we now use the npx *playwright show-report *command, the output clearly shows the viewport configuration and numbers of tests run.

Stepping Over Tests

The Playwright Inspector allows stepping over tests using the top menu. We can either click the Step over button or use the keyboard shortcut F10.

The current action is shown in the Playwright Inspector, and the selected element is highlighted in the browser window. The second half of the Playwright Inspector also shows the actionability log indicating the executed lines and the currently executing line.

Debug Dynamically Loading Elements

In the second test scenario, we wrote a test case for dynamically loading elements using the TypeScript API of Playwright. Dynamically loading elements make the perfect candidate for debugging as there is a chance of flakiness in such tests.

Debugging a single test can be started by firing the below command where the -g flag indicates we wish to run the single test specified by its name.

npx playwright test -g "dynamic element" --debug

We use the step over (F10) button and stop first after the scroll. The actionability logs clearly show the progress so far.

Before completing the click() action on the increase quantity button, we can see the count is 1. After stepping over, the count becomes 6, which is clear to see.

While the debugging provided simple insights, it’s very effective in the next line, where we are trying to verify that 5 images exist in the gallery. The debugging screen clearly shows the matched elements by the locator.

We can also use the debugging screen to locate other elements on the modal; for example, we want to find the locator for the ‘ADD TO CART’ button. We can click the ‘Pick Locator’ to enable the live locator. Once enabled, we click on the ‘ADD TO CART’ to let Playwright Inspector provide the locator in the text field next to ‘Pick Locator’.

This is a simple yet effective demo of live debugging of tests and how the Playwright Inspector can help make the life of automation teams build and improve the existing tests and test suites.

However, you can further scale your Playwright testing experience by running tests on the cloud-based grid. Digital experience testing platforms like LambdaTest lets you perform automation testing with Playwright on an online browser farm of 50+ real browsers and OS combinations.

It also allows you to achieve faster release cycles by executing Playwright tests in parallel.

Check our documentation: Getting Started with Playwright Testing

Looking to showcase your skills as a Playwright automation tester? LambdaTest’s Playwright 101 certification program is tailored for developers aiming to demonstrate their expertise in utilizing Playwright end to end testing of contemporary web applications.

Conclusion

This blog provides a glimpse into the world of test generation and debugging using the Playwright Inspector tool. However, there is much more to explore beyond the surface. Whether you lean towards Python or TypeScript, Playwright Inspector offers seamless integration with these widely used programming languages, empowering you with extensive test automation and debugging capabilities.

We witnessed the utilization of the Playwright Inspector tool with TypeScript. The versatility of Playwright Inspector, accommodating multiple programming languages according to the expertise and preferences of QA and automation teams, positions Playwright as an exceptional choice for automating applications across the board.

Daily usage, more experience, and experimenting with the Playwright Inspector tool can improve the ability to build robust and resilient test automation suites for any web application. Playwright Inspector tool also matures with each new version that is released.

Playwright Inspector is an indispensable tool for developers and QA professionals who must quickly create and debug automated tests. Its user-friendly interface makes it easy to write and run tests and even helps debug them.

One of the key advantages of Playwright Inspector is its ability to run tests on various devices and viewports. This means we can easily test our web application across different devices, screen sizes, and resolutions, which is crucial for ensuring a seamless user experience.
Additionally, the tool’s live element location feature makes it easy to identify and fix any issues with our website’s elements. So, if you’re not already using Playwright Inspector, it’s worth trying.

How To Find Elements Using Playwright Locators

Jaydeep Karale — Mon, 04 Dec 2023 06:08:56 +0000

End-to-end testing is essential for ensuring the quality and usability of a website or web application. And a crucial aspect of end-to-end testing is the ability to reliably, correctly, and easily locate elements on a web page. The process of locating elements involves identifying and interacting with elements on a web page, such as buttons, links, and text fields, to evaluate their behavior and functionality.

Web development frameworks and technologies are constantly evolving. Single Page Applications(SPA) are perfect examples where a single document is loaded, which receives dynamic updates, behaves differently across different browsers, uses asynchronous requests, and has complex state management.

The increasingly dynamic nature of web applications makes it paramount to have a robust, reliable, and accurate method for locating and interacting with elements on a web page. Resilient and non-flaky tests can help test every aspect of the website (or app). How can I not mention Playwright when referring to non-flakiness in tests 🙂

Playwright is an open-source automation testing framework, which enables reliable end-to-end testing of web applications. It supports multiple languages, including Python, JavaScript, Java, and .Net, making it flexible for different developer communities. It also works seamlessly across different browsers and operating systems.

One of the powerful ways to locate elements for web testing is by using Playwright locators. Playwright locators are the central piece of Playwright’s auto-waiting and retry-ability, making it easy for developers and testers to interact with specific elements on a web page, and it enables the creation of test scripts that can interact with those elements.

To understand the preferences and trends within the testing community, we conducted a LinkedIn poll asking, ‘What is your favorite element locator in test automation? The responses provided a clear preference, that is Xpath among professionals. This interesting revelation highlights the significant role of XPath in test automation.

Source

In this blog on Playwright locators, we will dive deep into various locator strategies that can be used with Playwright for finding web elements while performing automation testing. If you are preparing for an interview you can learn more through Playwright interview questions.

So, let’s get started!

Quick Recap about Playwright

Playwright is the latest entrant into the array of frameworks (e.g., Selenium, Cypress, etc.) available for web automation. It enables fast and reliable end-to-end testing for modern web apps.

At the time of writing this Playwright locators blog, the latest stable version of Playwright is 1.30.0, and Playwright is now consistently hitting the >20K download per day mark, as seen from PyPi Stats.

Below are the download trends of Playwright in comparison to a popular alternative, Selenium, taken from Pip Trends.

A key consideration when using any language, tool, or framework is its ease.

Revolutionize your UI testing with AI-powered Smart Visual UI Testing. Ensure visual perfection across 3000+ environments. Start Testing Now.

Key features of Playwright:

Support for all modern browsers including Chromium, Firefox, Microsoft Edge, and WebKit
Playwright APIs are available in different languages such as Python, Java, JavaScript, TypeScript, and .NET.
Playwright is cross-platform. Hence tests work seamlessly on Windows, macOS, and Linux in both headless & non-headless modes.
Playwright supports auto-wait, eliminating the need for artificial timeout, making the tests more resilient & less flaky.
Playwright locators provide unique & simple ways to find elements on websites built using modern frameworks.
Playwright offers a unique codegen tool that assists in locating elements

Playwright locators combined with its rich & easy-to-use APIs make it the perfect choice for end-to-end testing of web applications allowing simpler-than-ever access to elements on websites built using modern web frameworks. You can go through this blog on Playwright end-to-end testing to learn more about it.

In the further sections of this blog on Playwright locators, I will dive deep into the different locators that can be used for locating elements on the AUT.

To find more use cases of using Playwright, you can refer to this blog on Playwright for web scraping.

What are Playwright Locators?

The Playwright locators are at the heart of the Playwright’s ability to automate actions and locate elements on the web page. In layman’s terms, Playwright locators are a way for our scripts to interact with a specific element on a webpage.

Playwright locators are equipped with auto-wait and retry abilities. This means that the locator will wait for the elements to load & keep retrying automatically before throwing TimeoutError. You can learn more about it through this blog on handling exceptions in automation testing.

There are several ways of getting started with Playwright locators, first using the page.locator() method to create our locators, which can work with CSS or XPath, and secondly, using the built-in locators.

While Playwright is fully flexible in allowing us to build our custom locators using page.locator() the built-in locators are recommended and serve most use cases.

Key Features of Playwright Locators:

Built-in locators capable of locating elements using ARIA Roles, text, alt-text, placeholders, titles, labels, and custom test-ids.
Ability to chain & filtering locators provides precision to narrow the search for the element.
Fully flexible in working with CSS & XPath if required.
Locators work on the most up-to-date DOM everytime action is performed using them, ensuring reliable tests.
Built-in support for auto-wait and retry, helping write resilient and non-flaky tests.
Built-in methods available to perform various actions on located elements.

Run Automated Playwright Tests Online. Try LambdaTest Now!

How to install and set up Playwright?

Before we explore Playwright locators, let’s set up our development environment quickly. Also, if you already have Playwright installed on your machine, please hop on to the Sync vs Async Playwright section to know why I have used sync APIs for testing.

Playwright is flexible and allows working with various languages such as Python, NodeJs, Java, .NET, JavaScript, and TypeScript. For this blog on Playwright locators, we will use the Python API of Playwright.

Creating a dedicated virtual environment:

Create a dedicated folder for our project called playwright locators (This step is not mandatory but good practice).
Inside the folder we just created, use the built-in venv module to create a virtual environment named playwright locators.

Activate the virtual environment by calling the activate script.
Install the Playwright module using pip install pytest-playwright.
Lastly, install the required browsers using playwright install

All the tests written in this blog have been thoroughly tested on the following versions
Python 3.9.12, pytest 7.2.1, and Playwright 1.29.1.

Automate visual testing effortlessly with our Smart Visual UI Testing. Achieve flawless UIs on every device and browser. Try it Today.

Sync vs Async Playwright

As mentioned above, we will use the Python API of Playwright for this Playwright locators tutorial and more specifically, the sync_api version. The reason for choosing sync_api as mentioned in the answer on Stack Overflow is that the sync_api is simply a wrapper around Python’s asyncio_api. So Playwright makes async calls under the hood.

When using other languages based on the support, it’s best to choose the appropriate, i.e., sync or async API. Let’s use the Playwright Test Generator tool to confirm this understanding.

When running, the test for Python generates code that uses sync_api, as seen from the screenshots below.

When running, the test for Javascript generates code that uses async_api, as seen from the screenshots below.

So, when using Playwright with Python, feel free to use sync_api unless you need fine control over the request behavior in which you can use async_api.

Recommended Playwright Locators

Playwright provides flexibility to use the page.locator() method to locate elements using CSS & XPath, but it’s not recommended. We will discuss why it’s not recommended in the later section of this Playwright locator tutorial.

Instead, Playwright provides seven built-in locators recommended and sufficient for locating any elements on any web page or website. Let’s now explore in detail the recommended built-in Playwright locators one by one.

All the tests demonstrated hereafter have been run on the LambdaTest cloud grid. However, the tests are fully compatible with running on local machines. When running locally, just use the correct pytest fixture mentioned in the section below.

Cloud testing platforms like LambdaTest allow you to perform Playwright automated testing at scale, dramatically reducing the time taken to run your Playwright tests. You can run your tests on an online browser farm of 50+ browsers and browser versions of Chrome, Chromium, Microsoft Edge, Mozilla Firefox, and even Webkit.

You can also subscribe to the LambdaTest YouTube Channel and stay updated with the latest tutorial around Selenium testing, Cypress E2E testing, Appium, and more.

Prerequisites

To use LambdaTest with Playwright, you must set up the necessary imports and dependencies along with the username and access key to run the test on the LambdaTest cloud grid.

Setting up the imports and LambdaTest cloud grid username & access key

The load_dotenv(“sample.env”) reads the username & access key required to access the Playwright on the LambdaTest cloud grid. The username and access key are available on the LambdaTest Profile Page.

import json
import os
import re
import subprocess
import sys
import urllib


import pytest
from dotenv import load_dotenv


load_dotenv("sample.env")

Setting up the Capabilities

The capabilities dictionary contains the configuration of our test environment on the LambdaTest Playwright grid. The configurations encompass various parameters, such as the preferred browser, its specific version, the operating system required to execute the tests, and other relevant settings.

capabilities = {
    'browserName': 'Chrome',  # Browsers allowed: `Chrome`, `MicrosoftEdge`, `pw-chromium`, `pw-firefox` and `pw-webkit`
    'browserVersion': 'latest',
    'LT:Options': {
        'platform': 'Windows 10',
        'build': 'Playwright Locators Demo Build',
        'name': 'Playwright Locators Test For Windows 10 & Chrome',
        'user': os.getenv('LT_USERNAME'),
        'accessKey': os.getenv('LT_ACCESS_KEY'),
        'network': True,
        'video': True,
        'visual': True,
        'console': True,
        'tunnel': False,   # Add tunnel configuration if testing locally hosted webpage
        'tunnelName': '',  # Optional
        'geoLocation': '', # country code can be fetched from https://www.lambdatest.com/capabilities-generator/
    }
}

Setting up the pytest fixtures:

We set up two fixtures, one for our cloud grid and the other for our local grid. So it becomes easy to switch between local & cloud depending on where you want to run the tests.

Use the local_grid_page fixture when you run the tests on the local machine.

@pytest.fixture(name="local_grid_page")
def playwright_local_grid_page():
    with sync_playwright() as playwright:
        browser = playwright.chromium.launch(headless=True)
        page = browser.new_

Use the cloud_grid_page fixture when you wish to run the tests on the LambdaTest cloud grid.

@pytest.fixture(name="cloud_grid_page")
def playwright_local_grid_page():    
    with sync_playwright() as playwright:
        playwrightVersion = str(subprocess.getoutput('playwright --version')).strip().split(" ")[1]
        capabilities['LT:Options']['playwrightClientVersion'] = playwrightVersion        
        lt_cdp_url = 'wss://cdp.lambdatest.com/playwright?capabilities=' + urllib.parse.quote(json.dumps(capabilities))    
        browser = playwright.chromium.connect(lt_cdp_url)
        page = browser.new_page()    
        yield page

In this pytest Tutorial, learn how to use pytest fixtures with Selenium and how to set up your test using the pytest.fixture() decorator.

Locating Elements by Role in Playwright

The locator get_by_role() allows locating elements by their ARIA role, ARIA attributes, and accessible name. ARIA stands for Accessible Rich Internet Applications. It’s a set of attributes that can be added to HTML elements to help people who use assistive technologies, like screen readers, navigate and understand web content more easily.

ARIA roles are like labels for different parts of a website, like headings, buttons, and links. These labels help people who use assistive technologies understand the different parts of the website and how to use them.

Let’s understand the get_by_role() Playwright locator using the LambdaTest eCommerce website and one of the ARIA roles, a button.

Test Scenario:

Demo website home page should contain the ‘Search’ button.
‘Search’ button should have a CSS class ‘type-text’.

Sample Implementation:

# replace cloud_grid_page with local_grid_page while running on local
def test_homepage_contains_search_button(cloud_grid_page):
    cloud_grid_page.goto("https://ecommerce-playground.lambdatest.io/")
    search_button_locator = cloud_grid_page.get_by_role(role="button", name="Search")
    expect(search_button_locator).to_have_class("type-text")

Execution:

Code Walkthrough:

Upon inspection of the homepage we see that ‘Search’ is a button of the type submit and has a CSS class=’type-text’ assigned to it.
Use the Playwright locator get_by_role() with arguments as role=‘button’ and name=’Search’.
The expect() Playwright assertion then checks if the located element has class=type-text *using the *to_have_class() method.

It’s worth mentioning that for the get_by_role() Playwright locator, only the role argument is mandatory. All other arguments are optional, including the name we used. An important optional argument is exact. It can be used to force an exact case-sensitive and whole-string match.

Let’s now move to the next Playwright locator, where we will demo the exact match argument.

Streamline your app development with Visual Studio App Center on LambdaTest. Automate your app testing on real devices effortlessly. Learn How.

Locating Elements by Text in Playwright

The locator get_by_text() allows finding elements by the text it contains. This fully versatile Playwright locator can match exact string and substring and also allows using regular expressions.

This Playwright locator is recommended for finding non-interactive elements such as those contained within HTML tags div, span, and p. Let’s see this Playwright locator in action using a few scenarios to explore exact matches and regular expressions.

For this, we again use the LambdaTest eCommerce website.

Test Scenario:

Product page should contain the exact texts for product details:

Brand:
Viewed:
Reward Points:
Availability:

Sample Implementation:

# replace cloud_grid_page with local_grid_page while running on local
def test_product_details_text_should_be_visible(cloud_grid_page):    
    cloud_grid_page.goto(
        "https://ecommerce-playground.lambdatest.io/index.php?route=product/product&path=57&product_id=28"
    )
    brand_text_locator = cloud_grid_page.get_by_text(text="Brand:", exact=True)
    viewed_text_locator = cloud_grid_page.get_by_text(text="Viewed:", exact=True)
    points_text_locator = cloud_grid_page.get_by_text(text="Reward Points:", exact=True)
    availability_text_locator = cloud_grid_page.get_by_text(text="Availability", exact=True)
    expect(brand_text_locator).to_be_visible()
    expect(viewed_text_locator).to_be_visible()
    expect(points_text_locator).to_be_visible()
    expect(availability_text_locator).not_to_be_visible()

Execution:

Code Walkthrough:

Upon inspecting the product page, we see the details within the < span > tag.
The steps to navigate the product page remain the same as in the previous test case.
In the next steps, we use the get_by_text() Playwright locator to match the texts for ‘Brand:’, ‘Viewed:’, and ‘Reward Points:’. We use the expect() assertion on each of the three locators and call the to_be_visible() method.
For the ‘Availability’, we exclude the ‘:’ to demonstrate that the exact argument works. Since we know the exact match, in this case, will fail on the expect() assertion, we call the not_to_be_visible() method.
Playwright provides positive and negative assertion methods; we’ve used both in this example.

Locating Multiple Elements by Regular Expressions in Playwright

Whilst we saw exact matches while testing modern web applications, we frequently may need to look for approximate matches, and Playwright locators have us covered.

We can use regular expressions to locate multiple elements. Let’s quickly look at an example.

Test Scenario:

Product page multiple occurrences of the brand ‘HTC’.
There should be 10 matches.

Sample Implementation:

# replace cloud_grid_page with local_grid_page while running on local
def test_product_name_to_appear_more_than_once(cloud_grid_page):    
    cloud_grid_page.goto(
        "https://ecommerce-playground.lambdatest.io/index.php?route=product/product&path=57&product_id=28"
    )
    brand_name_locator = cloud_grid_page.get_by_text(re.compile("htc", re.IGNORECASE))
    expect(brand_name_locator).to_have_count(10)

Execution:

Code Walkthrough:

Upon inspecting the product page, we know that there are 10 occurrences of the brand name ‘htc’.
The part of opening the product page remains the same.
In preparing the locator, we use the Python ‘re’ module to match all occurrences and also use IGNORECASE.
On the expect() assertion, we call the to_have_count() method to complete our test.

Locating Form Elements by Label in Playwright

Almost all websites have form fields, and most form controls usually have dedicated labels that could be conveniently used to interact with the form. Playwright locators provide a convenient way of locating form elements using the get_by_label() locator.

Let’s jump into a demo using the LambdaTest eCommerce website.

Test Scenario:

The login form should have exactly one Email Address label.
The login form should have exactly one Password label.

Sample Implementation:

# replace cloud_grid_page with local_grid_page while running on local
def test_exactly_one_email_and_password_field(cloud_grid_page):    
    cloud_grid_page.goto(
        "https://ecommerce-playground.lambdatest.io/index.php?route=account/login"
    )
    email_address_locator = cloud_grid_page.get_by_label(text="E-Mail Address", exact=True)
    password_locator = cloud_grid_page.get_by_label(text="Password", exact=True)
    expect(email_address_locator).to_have_count(1)
    expect(password_locator).to_have_count(1)

Execution:

Code Walkthrough:

The part till we goto() the login page remains the same.
Initialize two locators using get_by_label(), one of Email & Password with the exact=True to confirm that only one login form element exists.
On the expect() assertion, we call the method to_have_count(1) to test only one of each email & password field.

Locating Input Elements by Placeholder in Playwright

Most websites have several forms for login, registration, reviews, and customer support. And forms usually have a placeholder text to assist the user in correctly filling forms.

Playwright locator get_by_placeholder() comes in handy when locating elements using the placeholder text. Our LambdaTest eCommerce demo website has a review form that can be used to explore this locator.

Test Scenario:

The review form should have one field for the customer name.
The review form should have one field for customer review.

Sample Implementation:

# replace cloud_grid_page with local_grid_page while running on local
def test_review_form_has_customername_customerreview_fields(cloud_grid_page):    
    cloud_grid_page.goto(
        "https://ecommerce-playground.lambdatest.io/index.php?route=product/product&path=25&product_id=28"
    )
    name_locator = cloud_grid_page.get_by_placeholder(text="Your Name", exact=True)
    review_locator = cloud_grid_page.get_by_placeholder(text="Your Review", exact=True)
    expect(name_locator).to_have_count(1)
    expect(review_locator).to_have_count(1)

Execution:

Code Walkthrough:

Upon inspecting the demo website, we can spot the placeholder texts for the review section.
We use the name of these placeholders as an argument to the get_by_placeholder() locator. We also only look for an exact matching by setting the argument exact=True.
Calling to_have_count(1) on the except() assertion then helps to test our scenario of only one reviewer name field and review input field.

Locating Image Elements by Alt Text in Playwright

All websites have images, and all images must have an alt-text. The reason it’s important to have alt-text is beyond the scope of this blog. Still, to provide a brief explanation, alt-text is important for accessibility, user experience, and image search SEO.

And Playwright has an efficient get_by_alt_text() locator to locate image and area elements using the alt-text attribute.

Below is the homepage of our demo website, and its logo can be used to demonstrate this Playwright locator effectively.

Test Scenario:

The logo with alt-text=”Poco Electro” should be visible.

Sample Implementation:

# replace cloud_grid_page with local_grid_page while running on local
def test_logo_with_alt_text_should_be_visible(cloud_grid_page):
    cloud_grid_page.goto(
        "https://ecommerce-playground.lambdatest.io/index.php?route=common/home"
    )
    logo_locator = cloud_grid_page.get_by_alt_text(text="Poco Electro", exact=True).first
    expect(logo_locator).to_be_visible()

Execution:

Code Walkthrough:

This is a rather simple one where we just get the alt-text *from the Chrome Developer Tools and pass it onto the *get_by_alt_text() locator.
Since there could be multiple uses of the same alt-text, we use the attribute first to narrow down our results to the first element.
The expect() then asserts if the selected element by the locator is visible.

Locating Elements by Title in Playwright

The HTML title attribute specifies additional information about an element. It is most commonly used on the < a > and < img > elements to provide a text description for screen readers and other assistive technologies. The text within the title attribute will typically appear as a tooltip when the mouse pointer hovers over the element.

Here’s what the title attribute attached to the product image looks like from our demo website. We can use the get_by_title() Playwright locator to locate elements by title. It’s worth pointing out that our demo website uses the same title text for all images. Hence our locator will return more than one element(20).

Test Scenario:

20 elements with title=’HTC Touch HD’ should be present.

Sample Implementation:

# replace cloud_grid_page with local_grid_page while running on local
def test_display_count_of_all_elements_with_title_htc_touch_hd(cloud_grid_page):    
    cloud_grid_page.goto(
        "https://ecommerce-playground.lambdatest.io/index.php?route=product/product&path=18&product_id=28"
    )
    alt_text_locator = cloud_grid_page.get_by_title(text=re.compile("htc touch hd", re.IGNORECASE))
    expect(alt_text_locator).to_have_count(20)

Execution:

Code Walkthrough:

We open the product page, as usual, using the page.goto() method.
Next, we pass the title text we want to locate. Notice the use of the regex Python module to ignore the case.
The expect() assertion then verifies if the locator can detect all 20 elements.

Locating Elements by Test ID in Playwright

The Playwright locators, which we have seen so far, are based on HTML tags or attributes assigned to each element. However, the problem with this approach is that these tags, such as roles and attributes may change over time. If this happens, our tests will fail and need to be refactored to account for the changes.

To avoid this, test-ids are the most resilient way of testing a web application. Developers & QA’s can agree and define explicit test-ids for elements. Using these test-ids to query the elements ensures that our tests continue to work even if the role, text, or title of the elements changes.

Playwright provides the get_by_test_id() locator for locating elements by predefined test-ids. The default attribute that the get_by_test_id() locator looks for is data-testid. This behavior can be easily changed by setting a custom attribute to look for playwright.selectors.set_test_id_attribute(“data-pw”)

Playwright Locators using CSS and XPath

Playwright is fully flexible, and while the recommended locators should always be used, there might be scenarios of personal preferences for using CSS or XPath to locate elements. For such cases, we need to use the page.locator() that takes a selector describing how to find the element on the page.

Below are some examples of creating locators using the page.locator() method using CSS and XPath. We can omit the CSS and XPath prefixes, which will still work fine.

# Construction locators using CSS
page.locator("css=button").click()
page.locator("button").click()
page.locator( "#tsf > div:nth-child(2) > div.A8SBwf > div.RNNXgb > div > div.a4bIc > input").click()

# Construction locators Xpath
page.locator("xpath=//button").click()
page.locator("//button").click()    
    page.locator('//*[@id="tsf"]/div[2]/div[1]/div[1]/div/div[2]/input').click()

Shortcomings of CSS and XPath with Playwright

As evident from the examples above, CSS & XPath-based locators are tied to the Document Object Model (DOM) and become complicated to read, maintain, and unreliable very quickly. The DOM is subject to change, and hence the locators using them lead to non-resilient tests.

So, it’s best to develop tests using the recommended built-in locators such as role, text, or even better define explicit testing contracts using test ids.

Filtering and Chaining Playwright Locators

In modern software development, which strongly advocates code reuse and principles like D.R.Y (Don’t Repeat Yourself), there may be instances where we need to refine our results to pinpoint particular elements.

We ran into this scenario of broad/multiple matches even in the examples we saw for the recommended Playwright locators for locating elements by text in Playwright.

To handle this narrowing down of elements and to do it efficiently, Playwright has us covered by providing the ability to filter and chain locators.

Filtering vs Chaining

Filtering and Chaining are two methods that can be used to narrow down locating elements on a web page.

Filtering is used to narrow down the search for elements on a web page by specifying additional conditions that must be met. For example, you can use the filter(has_text=) to find an element containing a specific text piece.

Chaining is used to combine multiple locators in a single search. For example, you can use the get_by_text() and get_by_role() locators to find an element with a specific text and a specific role.

In summary, Filtering is used to refine a search further after an element has been located, while Chaining combines multiple search criteria to locate an element.

Filtering Playwright Locators

Playwright locators can be filtered by text. This search is case-insensitive and can also be done via regular expression. Playwright locators can also be filtered using another locator. For both cases, the method used is the locator.filter().

To understand filtering by another locator, let’s use a new demo website LambaTest Playground which has a nice block containing list items. Here’s the test scenario.

Test Scenario:

Locate the list containing Input Forms.
Filter & locate the Input Form Submit list item.

Sample Implementation:

# replace cloud_grid_page with local_grid_page while running on local
def test_locator_filter_by_another_locator(cloud_grid_page):
    cloud_grid_page.goto(
        "https://www.lambdatest.com/selenium-playground/"
    )
    base_locator = cloud_grid_page.get_by_role("listitem")
    list_heading_locator = base_locator.filter(
        has=cloud_grid_page.get_by_text(text=re.compile("input form submit", re.IGNORECASE))
        )    
    expect(list_heading_locator).to_have_text('Input Form Submit')

Execution:

Code Walkthrough:

Upon inspection of the website using Chrome Developer Tools we see the presence of a list containing all the texts of the several different demos.
We form the base_locator using the get_by_role() locator and the ARIA role listitem.
This base_locator will contain all the lists on the page, and there are plenty.
So, we narrow down our lookup by calling the filter() method on our base_locator.
In the filter, we use the recommended get_by_text() locator and also make sure we handle case sensitivity using regular expressions by searching for the text ‘input for submit’, this filtered locator is called list_heading_locator.
On the filtered list_heading_locator we call the except() assertion and ensure we only have located the exact list item(for input form submit) that we intended to locate

Example: Filtering by Text

To understand filtering by text, let’s consider the same LambaTest Playground website but a different list, which has a lot of texts with the word ‘Table’.

Test Scenario:

Locate the list containing the Table.
The list has 5 items.

Sample Implementation:

# replace cloud_grid_page with local_grid_page while running on local
def test_locator_filter_by_text(cloud_grid_page):
    cloud_grid_page.goto(
        "https://www.lambdatest.com/selenium-playground/"
    )
    base_locator = cloud_grid_page.get_by_role("listitem")
    table_list_locator = base_locator.filter(
        has_text=re.compile("table", re.IGNORECASE)
        )    
    expect(table_list_locator).to_have_count(5)

Execution:

Code Walkthrough:

The steps till we set up the base_locator remain the same as above test_locator_filter_by_another_locator() test.
From there, instead of using another locator-based filter, we filter based on text=’table’ by passing it to the filter() method.
The demo website inspection clearly shows the ‘Table’ list has 5 items, which is what we assert in the except().

That is all about filtering locators. In summary, they allow us to narrow down our search, we need to call the filter() method on a locator to apply to the filter, and the Filtering can be done either by text or using another locator, which is simple and efficient.

Chaining Playwright Locators

It’s not always possible for a single locator to locate the exact element on a webpage. In such scenarios, Chaining is the second method to narrow the search to a specific element by combining multiple locators.

Let’s revisit the same scenario we saw in the filter, i.e., locating an element from a list. Still, we will use locator Chaining to find the element instead of Filtering.

Test Scenario:

Locate the list containing Input Forms and narrow it down to Input Form Submit.
The Input Form Submit should be a link. The link href attribute should contain the words input-form-demo.

Sample Implementation:

# replace cloud_grid_page with local_grid_page while running on local
def test_locator_chaining(cloud_grid_page):    
    cloud_grid_page.goto(
        "https://www.lambdatest.com/selenium-playground/"
    )
    input_form_locator = cloud_grid_page.get_by_role("listitem").get_by_text(text=re.compile("input form submit", re.IGNORECASE))
    expect(input_form_locator).to_have_attribute(name="href", value=re.compile("input-form-demo", re.IGNORECASE))

Execution:

Code Walkthrough:

The DOM structure upon inspection clearly shows that we have a list & within each list is a link to the individual demo.
Hence, the first locator get_by_role(“listitem”) will locate all the lists on the page. There are approximately 6.
We then chain the get_by_text(text=re.compile(“input form submit”, re.IGNORECASE) to narrow down the result set to exactly match the input form submit list item.
Lastly, the except() assertion checks if the located element has a link, i.e., href attribute, and does a regular expression match to ensure the link contains certain keywords we know are necessary
So, that is about Chaining. Again, Filtering is used to refine a search further after an element has been located, while chaining combines multiple search criteria to locate an element.

Playwright Locator Methods

Throughout this Playwright locators blog, I have touched upon the various methods available in Playwright, such as filter(), first(), get_attribute(), etc. However, that is just the tip of the iceberg. There are numerous methods available to locate and perform desired actions using Playwright locators.

A complete list of available methods can be found in the official documentation. I strongly urge everyone to go over the Locators API documentation and explore the available methods of this super-powerful library.

Constructing Locators using Playwright’s Test Generator

We have been writing the tests manually by inspecting the DOM. But since we are talking about an automation framework, it only makes sense that Playwright has something which can assist and automate part of locating elements on a web page. Playwright has a powerful feature called the Test Generator, which can help you locate the elements and make it easier to write tests.

My only complaint about this feature is that it’s called Test Generator. The command to start it has the word codegen, and the subsequent generator that starts has the title Playwright Inspector. I sincerely wish Microsoft would fix this and agree on one name to simplify lives.

To start the Test Generator, we simply use the command shown below.

playwright codegen https://ecommerce-playground.lambdatest.io/

Feel free to replace the URL with the website you intend to write tests for.

Test Generator in Action

Here’s what the Test Generator looks like and the opened Chromium browser where we can perform the actions we want. Based on our actions, the Test Generator will generate the code for us.

The cool thing about the Test Generator is that you can choose your intended language. For this blog, as you know, I have chosen Python, but Playwright allows you to choose whichever you wish from the drop-down highlighted in red.

Based on your selection, the Test Generator will write the code for us.

Let’s say we want to locate the search bar, type in mobile, and hit the search button. Here is the snapshot of the actions performed and the code the Test Generator was able to write for us with all the locators. We can then use these locators to run tests using the except() assertion.

from playwright.sync_api import Page, expect


def test_example(page: Page) -> None:
    page.goto("https://ecommerce-playground.lambdatest.io/")
    page.get_by_role("textbox", name="Search For Products").click()
    page.get_by_role("textbox", name="Search For Products").fill("mobile")
    page.get_by_role("button", name="Search").click()

The Playwright Test Generator tool also comes with several built-in options to emulate devices, viewport sizes, color schemes, geolocation, timezone, etc.

Let’s see a quick demo of two of these features, and feel free to experiment with the other by referencing the official documentation.

Emulate Viewport Size:

Notice how Playwright generates all the boiler-plate code for setting the viewport as a fixture.

playwright codegen --viewport-size=800,600 https://ecommerce-playground.lambdatest.io/

Emulate Devices:

Notice how Playwright generates all the boiler-plate code for setting the device selected for testing as a fixture.

playwright codegen --device=”iPhone11” https://ecommerce-playground.lambdatest.io/

Want to demonstrate your expertise as a Playwright automation tester? LambdaTest’s Playwright 101 certification program is aimed at developers who want to showcase their proficiency in using Playwright for end-to-end testing of modern web applications.

Conclusion

That is it for this blog !!! In conclusion, Playwright locators are powerful tools that allow you to locate and interact with elements on a web page with the ability to locate elements by their attributes, role, text, label, alt-text, etc. Understanding the locators, Filtering, and Chaining and how to use them effectively is essential for writing efficient and reliable automated tests with Playwright.

The Playwright Test Generator tool can help you quickly and easily create boilerplate code for locating elements. The time and effort saved can be used to focus on more important tasks like writing resilient tests and improving coverage.

We have explored in great detail the world of Playwright Locators. Even with the level of detail, I’ve tried to cover, there’s much more to explore and experiment with, and I hope this blog serves as a solid foundation for that.

How To Use Playwright For Web Scraping with Python

Jaydeep Karale — Thu, 30 Nov 2023 13:14:04 +0000

In today’s data-driven world, the ability to access and analyze large amounts of data can give researchers, businesses & organizations a competitive edge. One of the most important & free sources of this data is the Internet, which can be accessed and mined through web scraping.

Web scraping, also known as web data extraction or web harvesting, involves using code to make HTTP requests to a website’s server, download the content of a webpage, and parse that content to extract the desired data from websites and store it in a structured format for further analysis.

When it comes to data extraction & processing, Python has become the de-facto language in today’s world. In this Playwright Python tutorial on using Playwright for web scraping, we will combine Playwright, one of the newest entrants into the world of web testing & browser automation with Python to learn techniques for Playwright Python scraping.

The reasons for choosing Playwright over some popular alternatives are its developer-friendly APIs, automatic waiting feature, which avoids timeouts in case of slow-loading websites, superb documentation with examples covering various use cases, and a very active community.

So, let’s get started.

Key Use Cases of Web Scraping

Now, let’s explore some of the most popular web scraping use cases.

Price & Product Comparison for E-Commerce

Extracting prices, products, and images from e-commerce websites to gain insights about pricing & comparison with competitors.

Data for Machine Learning Models

Data scientists can use web scraping to get access to or create data sets for various use cases, such as feeding it to machine learning models.

Aggregate Job Listings

Web scraping is also useful for downloading job listings from various websites and making them available over a single channel.

Aggregate Discounts From Travel Websites

Aggregator websites that display the best hotel or flight ticket prices also use web scraping to get pricing data from various websites.

Master visual regression testing tools with our comprehensive guide. Dive into best practices and elevate your testing strategies.

A Word of Caution: Responsible Web Scraping

Whilst web scraping is a powerful tool, there are a few ethical & potentially legal considerations to consider when doing web scraping.

Respect terms of use

Many websites have terms of use that prohibit or limit web scraping. It is important to read and understand these terms before beginning any web scraping projects and to obtain permission if necessary.

Sensitive or protected data

Don’t burden servers

By following these guidelines and using web scraping responsibly, you can ensure that your web scraping projects are legal and ethical and that you are not causing harm to the websites you are scraping.

Having seen so many use cases, it’s evident that the market for web scraping is huge. And as the market grows for anything, so do the available tools. In this Playwright for web scraping tutorial, we will explore in-depth web scraping with Playwright in Python and how it can extract data from the web.

What is Playwright?

Playwright is the latest entrant into the array of frameworks (e.g., Selenium, Cypress, etc.) available for web automation testing. It enables fast and reliable end-to-end testing for modern web apps.

At the time of writing this Playwright for web scraping tutorial, the latest stable version of Playwright is 1.28.0, and Playwright is now consistently hitting the >20K download per day mark, as seen from PyPi Stats.

Below are the download trends of Playwright in comparison to a popular alternative, Selenium, taken from Pip Trends.

A key consideration to make when using any language, tool or framework is the ease of its use. Playwright is a perfect choice for web scraping because of its rich & easy-to-use APIs, which allow simpler-than-ever access to elements on websites built using modern web frameworks. You can learn more about it through this blog on testing modern web applications with Playwright.

Enhance your visual testing skills with our in-depth tutorial. Discover the secrets to flawless user interfaces. Explore Now.

Features of Playwright

Some unique and key features of Playwright are

Cross-Browser

Playwright supports all modern rendering engines such as Chromium, Firefox, and WebKit, which makes it a good choice when it comes to working & testing across several different browsers.

Cross-Language

Playwright APIs are available in different languages such as Python, Java, JavaScript, TypeScript & .NET, making it easier for developers from various language backgrounds to implement web scraping & browser-related tasks.

Cross-Platform

Websites built using modern web frameworks must be tested across all operating systems to ensure they render correctly on each of them. Playwright works seamlessly on Windows, macOS, and Linux in both headless & headed modes.

Auto-Wait

Playwright supports auto-wait, eliminating the need for artificial timeout, making the tests more resilient & less flaky

Web-first Assertions

Playwright assertions are explicitly created for the dynamic web. Checks are automatically retried until the necessary conditions are met, making it an ideal candidate for testing websites built using modern web frameworks.

Locators

Playwright’s locators provide unique & simple ways to find elements on websites built using modern web frameworks. Later in this Playwright for web scraping tutorial, we will deep dive into Playwright’s locators and why they make life so much easier.

Codegen

Playwright offers a unique codegen tool that can essentially write the code for you. You can start the codegen using the playwright codegen websitename and perform the browser actions. The codegen will record and provide boilerplate code that can be used or adjusted per our requirements.

Now that we know what Playwright is, let’s go ahead and explore how we can leverage its Python API for web scraping, starting firstly with installation & setup.

Discover the top 25 visual testing tools of 2023 for a seamless user experience. Find your ideal tool for flawless UIs.

Why Playwright for Web Scraping with Python?

As mentioned above, it’s possible to use Playwright for web scraping with different languages such as JavaScript, TypeScript, Java, .Net, and Python. So, it is necessary to understand why Python.

I have been programming for ten years using languages such as C++, Java, JavaScript & Python, but in my experience, Python is the most developer-friendly and productivity-oriented language.

It abstracts unnecessary complications of certain other programming languages and lets developers focus on writing quality code and shorten the delivery time whilst also enjoying writing the code.

A quick case for why I love Python automation testing & why we choose Playwright for web scraping, specifically using its Python API.

Easy to learn & use

The Zen Of Python, which defines the guiding principle of Python’s design, mentions ‘Simple Is Better Than Complex’. So, Python is a language developed explicitly with productivity, ease of use, and faster delivery in mind. It’s one of the easiest, most fun, and fastest programming languages to learn and use.

De-facto choice for processing data

Python has become the de-facto language for working with data in the modern world. Various packages such as Pandas, Numpy, and PySpark are available and have extensive documentation and a great community to help write code for various use cases around data processing. Since web scraping results in a lot of data being downloaded & processed, Python is a very good choice. You can learn more about it through this blog on web scraping with Python.

Widely used in Industry

Python is now widely used in almost all areas of the software development lifecycle, including development, testing, DevOps, and support. Its adoption, especially since the release of the 3.X versions, has been phenomenal.

Great community & ecosystem

The Python ecosystem is mature and has a vast community and a wide range of packages available in the Python ecosystem for processing data.

With an understanding of why we chose to work with Playwright for web scraping in Python, let’s now look at Playwright’s Locators. Playwright supports a variety of locator strategies, including CSS Selectors, XPath expressions, and text content matching.

Locators are a critical component of Playwright, making web browser-related tasks possible, easy, reliable, and fun.

Run Automated Playwright Tests Online. Try LambdaTest Now!

Understanding Playwright Locators

Locators are the centerpiece of the Playwright’s ability to automate actions & locate elements on the browser.

Simply put, locators are a way of identifying a specific element on a webpage so that we can interact with it in our scripts.

Key Features of Playwright Locators

Precision

Locators allow you to specify exactly which element you want to interact with on a web page. This can be useful when there are multiple elements on the page with similar attributes or characteristics. You can use a locator to select a specific element rather than just the first one that matches the criteria.

Flexibility

Playwright provides several different types of locators, including CSS Selectors, XPath, and text content, so you can choose the one that best suits your needs. This allows you to tailor your locators to the specific structure and content of the web page you are working with.

Up-to-date DOM Elements

Every time a locator is used for an action, an up-to-date DOM element is located on the page. If the DOM changes between the calls due to re-render, the new element corresponding to the locator will be used.

In the below example snippet, the button element will be located twice: once for the hover() action and once for the click() action to ensure we always have the latest data. This feature is available out of the box without needing additional code.

**Note: In Playwright, waits are unnecessary because it automatically waits for elements to be available before interacting with them. This means you do not have to manually add delays or sleep in your test code to wait for elements to load.

Additionally, Playwright includes many built-in retry mechanisms that make it more resilient to flaky tests. For example, if an element is not found on the page, Playwright will automatically retry for a certain amount before giving up and throwing an error. This can help to reduce the need for explicit waits in your tests.

You can learn more about it through this blog on types of waits.

Support for multiple browsers
Playwright supports all modern rendering engines, including WebKit, Chromium, and Firefox, so you can use the same locators and code across different browsers.
Test Mobile Web
Native mobile emulation of Google Chrome for Android and Mobile Safari. The same rendering engine works locally or if you wish to choose so, in the Cloud.

The below table summarizes some built-in locators available as part of the Playwright

Playwright Setup & Installation

When programming in Python it’s a de-facto approach to have a separate virtual environment for each project. This helps us manage dependencies better without disturbing our base Python installation.

Virtual Environment & Playwright Installation

Create a dedicated folder for the project called playwrightwebscraping. (This step is not mandatory but is good practice).
Next, using Python’s built-in venv module, let’s create a virtual environment named playwrightplayground and activate it by calling the activate script.

3.Lastly, install the Playwright module from the Python package index PyPi using the command pip install playwright.

Downloading Browsers for Playwright

After completing the installation of the Playwright Python package, we need to download & install browser binaries for Playwright to work with.

By default, Playwright will download binaries for Chromium, WebKit & Firefox from Microsoft CDN, but this behavior is configurable. The available configurations are as below.

Skip Downloads of Browser Binaries
Skip the download of binaries altogether in case testing needs to be performed on a cloud-based grid rather than locally. In such cases, we may not need the browsers downloaded on local systems. This can be done by setting the environment variable PLAYWRIGHT_SKIP_BROWSER_DOWNLOAD.

PLAYWRIGHT_SKIP_BROWSER_DOWNLOAD=1 python -m playwright install
Downloads of Browser Binaries from Different Repositories
As a good practice and for security reasons, organizations may not allow connections to Microsoft CDN repositories, which Playwright downloads the browsers from. In such cases, the environment variable PLAYWRIGHT_DOWNLOAD_HOST can be set to supply a link to a different repository.

PLAYWRIGHT_DOWNLOAD_HOST= playwright install
Downloads of Browser Binaries Via Proxy
Most organizations route requests to the internet via a Proxy for better security. In such cases, Playwright browser download can be done by setting the HTTPS_PROXY environment variable before installation.

HTTPS_PROXY= playwright install
Downloads of Single Browser Binary
Download only a single browser binary depending on your needs is also possible, in which case the install commands needed should be supplied with the browser name, for example, playwright install firefox

To keep things simple we install all browsers by using the command playwright install. This step can be skipped entirely if you run your code on cloud Playwright Grid, but we will look at both scenarios, i.e., using Playwright for web scraping locally and on a cloud Playwright Grid provided by LambdaTest.

Setup Playwright Project in Visual Studio Code

If you have Visual Studio Code(VS Code) already installed the easiest way to start it up is to navigate to the newly created project folder and type code.

This is how the VS Code will look when it opens. We now need to select the interpreter, i.e., the Python installation, from our newly created virtual environment.

Press Ctrl + Shift + P to open up the command palette in VS Code and type Python: Select Interpreter and click it.

VS Code will automatically detect the virtual environment we created earlier and recommend it at the top, select it. If VS Code does not auto-detect, click on the ‘Enter interpreter path..’ and navigate to playwrightplayground > Scripts > Python and select it.

You can verify the virtual environment by pressing the ctrl + (tilt), which will open up the VS Code terminal & activate the virtual environment. An active environment is indicated by its name before the path within round brackets.

With the setup and installation out of the way, we are now ready to use Playwright for web scraping with Python.

Demonstration: Using Playwright for Web Scraping with Python

For demonstration, I will be scraping information from two different websites. I will be using the XPath locator in the second scenario. This will help you in choosing the best-suited locator for automating the tests.

So, let’s get started…

Test Scenario 1: Web Scraping E-Commerce Website

In the first demo, we are going to scrape a demo E-Commerce website provided by LambdaTest for the following data:

Product Name
Product Price
Product Image URL

Here is the Playwright for web scraping scenario that will be executed on Chrome on Windows 10 using Playwright Version 1.28.0. We will run the Playwright test on cloud testing platforms like LambdaTest.

By utilizing LambdaTest, you can significantly reduce the time required to run your Playwright Python tests by leveraging an online browser farm that includes more than 50 different browser versions, including Chrome, Chromium, Microsoft Edge, Mozilla Firefox, and Webkit.

You can also subscribe to the LambdaTest YouTube Channel and stay updated with the latest tutorial around Playwright browser testing, Cypress E2E testing, Mobile App Testing, and more.

However, the core logic remains unchanged even if the web scraping has to be done using a local machine/grid.

Test Scenario:

Go to https://ecommerce-playground.lambdatest.io/.
Click on ‘Shop by Category’ & select ‘Software’.
Adjust the ‘Show’ filter to display 75 results.
Scrape the product name, price & image URL.

Version Check:

When writing this blog on using Playwright for web scraping, the version of Playwright is 1.28.0, and the version of Python is 3.9.12. The code is fully tested and working on these versions.

Implementation:

You can clone the repo by clicking on the button below.
GitHub - jaydeepkarale/python_playwright_webscraping

import json
import logging
import os
import subprocess
import sys
import time
import urllib
from logging import getLogger

from dotenv import load_dotenv
from playwright.sync_api import sync_playwright

# setup basic logging for our project which will display the time, log level & log message
logger = getLogger("webscapper.py")
logging.basicConfig(
    stream=sys.stdout,  # uncomment this line to redirect output to console
    format="%(message)s",
    level=logging.DEBUG,
)

# LambdaTest username & access key are stored in an env file & we fetch it from there using python dotenv module
load_dotenv("sample.env")

capabilities = {
    "browserName": "Chrome",  # Browsers allowed: `Chrome`, `MicrosoftEdge`, `pw-chromium`, `pw-firefox` and `pw-webkit`
    "browserVersion": "latest",
    "LT:Options": {
        "platform": "Windows 10",
        "build": "E Commerce Scrape Build",
        "name": "Scrape Lambda Software Product",
        "user": os.getenv("LT_USERNAME"),
        "accessKey": os.getenv("LT_ACCESS_KEY"),
        "network": False,
        "video": True,
        "console": True,
        "tunnel": False,  # Add tunnel configuration if testing locally hosted webpage
        "tunnelName": "",  # Optional
        "geoLocation": "",  # country code can be fetched from https://www.lambdatest.com/capabilities-generator/
    },
}


def main():
    with sync_playwright() as playwright:
        playwright_version = (
            str(subprocess.getoutput("playwright --version")).strip().split(" ")[1]
        )
        capabilities["LT:Options"]["playwrightClientVersion"] = playwright_version
        lt_cdp_url = (
            "wss://cdp.lambdatest.com/playwright?capabilities="
            + urllib.parse.quote(json.dumps(capabilities))
        )
        logger.info(f"Initiating connection to cloud playwright grid")
        browser = playwright.chromium.connect(lt_cdp_url)        
        # comment above line & uncomment below line to test on local grid
        # browser = playwright.chromium.launch(headless=False)
        page = browser.new_page()
        try:            
            # section to navigate to software category  
            page.goto("https://ecommerce-playground.lambdatest.io/")
            page.get_by_role("button", name="Shop by Category").click()
            page.get_by_role("link", name="Software").click()
            page_to_be_scrapped = page.get_by_role(
                "combobox", name="Show:"
            ).select_option(
                "https://ecommerce-playground.lambdatest.io/index.php?route=product/category&path=17&limit=75"
            )
            page.goto(page_to_be_scrapped[0])

            # Since image are lazy-loaded scroll to bottom of page
            # the range is dynamically decided based on the number of items i.e. we take the range from limit
            # https://ecommerce-playground.lambdatest.io/index.php?route=product/category&path=17&limit=75
            for i in range(int(page_to_be_scrapped[0].split("=")[-1])):
                page.mouse.wheel(0, 300)
                i += 1
                time.sleep(0.1)
            # Construct locators to identify name, price & image
            base_product_row_locator = page.locator("#entry_212408").locator(".row").locator(".product-grid")
            product_name = base_product_row_locator.get_by_role("heading")
            product_price = base_product_row_locator.locator(".price-new")
            product_image = (
                base_product_row_locator.locator(".carousel-inner")
                .locator(".active")
                .get_by_role("img")
            )            
            total_products = base_product_row_locator.count()
            for product in range(total_products):
                logger.info(
                    f"\n**** PRODUCT {product+1} ****\n"
                    f"Product Name = {product_name.nth(product).all_inner_texts()[0]}\n"
                    f"Price = {product_price.nth(product).all_inner_texts()[0]}\n"
                    f"Image = {product_image.nth(product).get_attribute('src')}\n"
                )
            status = 'status'
            remark = 'Scraping Completed'
            page.evaluate("_ => {}","lambdatest_action: {\"action\": \"setTestStatus\", \"arguments\": {\"status\":\"" + status + "\", \"remark\": \"" + remark + "\"}}")            
        except Exception as ex:
            logger.error(str(ex))


if __name__ == "__main__":
    main()

Code Walkthrough:

Let’s now do a step-by-step walkthrough to understand the code.

Step 1 — Setting up imports

The most noteworthy imports are

1 from dotenv import load_dotenv

The reason for using the load_dotenv library is that it reads key-value pairs from a .env file(in our case sample.env) and can set them as environment variables automatically. In our case, we use it to read the access key & username from a sample.env required to access the cloud-based Playwright Grid.

It saves the trouble of setting environment variables manually & hence the same code can seamlessly be tested on different environments without any manual intervention.

1 from playwright.sync_api import sync_playwright

Playwright provides both sync & async API to interact with web apps, but for this blog on using Playwright for web scraping, we are going to use the sync_api, which is simply a wrapper around the asyncio_api that abstracts away the need to implement async functionality.

For more complicated scenarios where there is a need for fine-grained control when dealing with specific scenarios on websites built using modern web frameworks, we can choose to use the async_api.

For most use cases, the sync_api should suffice, but it’s a bonus that the async_api does exist and can be leveraged when needed.

Step 2 — Setting up logging & reading username & access key

In the next step, we set up logging to see the execution of our code & also print out the product name, price & link to image. Logging is the recommended practice and should be preferred to print() statements almost always.
The load_dotenv(“sample.env”) reads the username & access key required to access our cloud-based Playwright grid. The username and access key are available on the LambdaTest Profile Page.

Step 3 — Setting up desired browser capabilities

We set up the browser capabilities required by the cloud-based Playwright automated testing grid in a Python dictionary. Let us understand what each line of this configuration means.

browserName is used to specify the browser the test/code should run on. All modern browsers, such as Chrome, Firefox, Microsoft Edge & WebKit.
browserVersion is used to specify the version of the browser.
platform is used to specify the operating system the test should run on such as Windows, macOS, or Linux.
build is used to specify the name under which the tests will be grouped.
name is used to specify the name of the test.
user & access key are our credentials to connect to the cloud Playwright grid.
network is used to specify whether the cloud Playwright grid should capture network logs.
video is used to specify if the cloud Playwright grid should capture video of the entire test execution.
tunnel & tunnelName are used to specify tunnel details in case the website we use isn’t publicly hosted over the internet.

Step 4 — Initializing browser context & connecting to cloud Playwright Grid

Create a ContextManager for the sync_playwright() function provided by Playwright.
Use Python’s built-in subprocess module to run the playwright –version command to extract the Playwright version.
Add playwright_version to the config dictionary of our cloud Playwright grid.
Prepare the WebSocket URL for our cloud Playwright grid so that we can leverage their infrastructure to run the script.
Use the standard connect method, which uses the Playwright’s built-in browser server to handle the connection. This is a faster and more fully-featured method since it supports most Playwright parameters (such as using a proxy if working behind a firewall).
Create a page in the browser context.

Step 5 — Open the website to scrape.

Open the website to scrape using the page context.

Step 6 — Click on ‘Shop by Category’.

‘Shop By Category’ is a link with the ‘button’ role assigned to it. Hence, we use Playwright‘s get_by_role() locator to navigate to it & perform the click() action.

Step 7 — Click on the ‘Software’.

Inspection of the ‘Software’ element shows that it’s a ‘link’ with name in a span. So, we use the built-in locator get_by_role() again and perform click() action.

Step 8 — Adjust the product drop down to get more products.

By default, the ‘Software’ page displays 15 items, we can easily change it to 75, which is nothing but a link to the same page with a different limit. Get that link and call the page.goto() method.

Step 9 — Loading Images.

The images on the website are lazy-loaded, i.e., only loaded as we bring them into focus or simply scroll down to them. To learn more about it, you can go through this blog on a complete guide to lazy load images.
We use Playwright’s mouse wheel function to simulate a mouse scroll.

Step 10 — Preparing base locator.

Notice that all the products are contained within two divs with id=entry_212408 and class=row. Each product then has a class=product-grid. We use this knowledge to form our base locator.

The base locator will then be used to find elements, such as name, price & image.

Step 11 — Locating product name, price & image.

With respect to the base locator, the location of other elements becomes easy to capture.

Product Name is contained within an h4 tag.
Product Price is contained in a div with class=price-new.
Image is present in class=carousel-inner active.

Step 12 — Scraping the data.

Now that we have all the elements located, we simply iterate over the total products & scrape them one by one using the nth() method.

The total number of products is obtained by calling the count() method on base_product_row_locator. For product name & price, we fetch text using the all_inner_texts(), and image URL is retrieved using the get_attribute(‘src’) element handle.

Execution:

Et voilà! Here is the truncated execution snapshot from the VS Code, which shows data of the first 5 products.

Here is a snapshot from the LambdaTest dashboard, which shows all the detailed execution, video capture & logs of the entire process.

Test Scenario 2: Web Scraping Selenium Playground

Let’s take another example where I will be scraping information from the LambdaTest Selenium Playground.
In this demonstration, we scrape the following data from the LambdaTest Selenium Playground:

Heading of section
Name of individual demo
Link to individual demo

One important change we are going to make in this demo to show the versatility of Playwright for web scraping using Python is

Use of ‘XPath’ in combination with locators to find elements.

Here is the scenario for using Playwright for web scraping, which will be executed on Chrome on Windows 10 using Playwright Version 1.28.0.

Test Scenario:

Go to ‘https://www.lambdatest.com/selenium-playground/’
Scrape the product heading, demo name & link of demo.
Print the scraped data.

Version Check:

At the time of writing this blog on using Playwright for web scraping, the version of Playwright is 1.28.0, and the version of Python is 3.9.12.

The code is fully tested and working on these versions.

Implementation:

Clone the Playwright Python WebScraping Demo GitHub repository to follow the steps mentioned further in the blog on using Playwright for web scraping
GitHub - jaydeepkarale/python_playwright_webscraping

import json
import logging
import os
import subprocess
import sys
import time
import urllib
from logging import getLogger

from dotenv import load_dotenv
from playwright.sync_api import sync_playwright

logger = getLogger("seleniumplaygroundscrapper.py")
logging.basicConfig(
    stream=sys.stdout,
    format="%(message)s",
    level=logging.DEBUG,
)

# Read LambdaTest username & access key from env file
load_dotenv("sample.env")

capabilities = {
    "browserName": "Chrome",
    "browserVersion": "latest",
    "LT:Options": {
        "platform": "Windows 10",
        "build": "Selenium Playground Scraping",
        "name": "Scrape LambdaTest Selenium Playground",
        "user": os.getenv("LT_USERNAME"),
        "accessKey": os.getenv("LT_ACCESS_KEY"),
        "network": False,
        "video": True,
        "console": True,
        "tunnel": False,  
        "tunnelName": "",  
        "geoLocation": "",
    },
}


def main():
    with sync_playwright() as playwright:
        playwright_version = (
            str(subprocess.getoutput("playwright --version")).strip().split(" ")[1]
        )
        capabilities["LT:Options"]["playwrightClientVersion"] = playwright_version
        lt_cdp_url = (
            "wss://cdp.lambdatest.com/playwright?capabilities="
            + urllib.parse.quote(json.dumps(capabilities))
        )
        logger.info(f"Initiating connection to cloud playwright grid")
        browser = playwright.chromium.connect(lt_cdp_url)
        # comment above line & uncomment below line to test on local grid
        # browser = playwright.chromium.launch()
        page = browser.new_page()
        try:                        
            page.goto("https://www.lambdatest.com/selenium-playground/")
            # Construct base locator section
            base_container_locator = page.locator("//*[@id='__next']/div/section[2]/div/div/div")
            for item in range(1, base_container_locator.count()+1):                
                # Find section, demo name & demo link with respect to base locator & print them
                locator_row = base_container_locator.locator(f"//div[{item}]")                            
                for inner_item in range(0, locator_row.count()):
                    logger.info(f"*-*-"*28)
                    logger.info(f'Section: {locator_row.nth(inner_item).locator("//h2").all_inner_texts()[0]}\n')
                    for list_item in range(0,locator_row.nth(inner_item).locator("//ul/li").count()):
                        logger.info(f'Demo Name: {locator_row.nth(inner_item).locator("//ul/li").nth(list_item).all_inner_texts()[0]}')
                        logger.info(f'Demo Link: {locator_row.nth(inner_item).locator("//ul/li/a").nth(list_item).get_attribute("href")}\n')
            status = 'status'
            remark = 'Scraping Completed'
            page.evaluate("_ => {}","lambdatest_action: {\"action\": \"setTestStatus\", \"arguments\": {\"status\":\"" + status + "\", \"remark\": \"" + remark + "\"}}")

        except Exception as ex:
            logger.error(str(ex))        




if __name__ == "__main__":
    main()

Code Walkthrough:

Let’s now do a step-by-step walkthrough to understand the code.

Step 1 — Step 4

Include the imports, logging, cloud Playwright testing grid & browser context setup that remain the same as the previous demonstration; hence, refer to them above.

Step 5 — Open the LambdaTest Selenium Playground Website

Use the page created in the browser context to open the LambdaTest Selenium Playground website, which we will scrape.

Step 6 — Construct the base locator

Inspecting the website in Chrome Developer Tools, we see that there is a master container that holds all the sub-blocks. We will use this to construct our base locator by copying the XPath.

Step 7 — Locate the section, demo name, and demo link

We repeat the inspection using Chrome Developer Tools, and it’s easy to spot that data is presented in 3 divs. Within each div, there are then separate sections for each item.

Based on the inspection, we iterate over the base locator and for each div

get the heading using its relative XPath //h2.
get the text from the link using Xpath //ul/li and all_inner_texts() method.
get the link url using Xpath //ul/li/a and get_attribute(‘href’) element handle.

The outermost for loop iterates over the outer container, the inner for loop gets the section title & the innermost for loop is for iterating over the list.

Execution:

Hey presto !!! Here is the truncated execution snapshot from the VS Code. We now have a collection of tutorials to visit whenever we wish to.

Here is a snapshot from the LambdaTest dashboard, which shows all the detailed execution along with video capture & logs of the entire process.

The Playwright 101 certification by LambdaTest is designed for developers who want to demonstrate their expertise in using Playwright for end-to-end testing of modern web applications. It is the ideal way to showcase your skills as a Playwright automation tester.

Conclusion

Python Playwright is a new but powerful tool for web scraping that allows developers to easily automate and control the behavior of web browsers. Its wide range of capabilities & ability to support different browsers, operating systems, and languages makes it a compelling choice for any browser related task.

In this blog on using Playwright for web scraping, we learned in detail how to set up Python and use it with Playwright for web scraping using its powerful built-in locators using both XPath & CSS Selectors.

It is well worth considering Python with Playwright for web scraping in your next scraping project, as it is a valuable addition to the web scraping toolkit.