Forem: GaryParker12

Playwright Tutorial: Getting Started With Playwright Framework

GaryParker12 — Tue, 06 Dec 2022 13:12:17 +0000

Playwright is a framework that I’ve always heard great things about but never had a chance to pick up until earlier this year. And since then, it’s become one of my favorite test automation frameworks to use when building a new automation project. It’s easy to set up, feature-packed, and one of the fastest, most reliable frameworks I’ve worked with.

I’m going to get you through this Playwright tutorial, which will enable you to write end-to-end tests for your future projects. We will also dig into the extensive features it offers, how we can prepare tests for execution on the LambdaTest cloud grid, and an overview of other popular integrations.

In this Playwright testing tutorial, I’ll be stepping through each part of the process so you can follow along, from the initial installation of the Playwright framework until the full execution of a test suite.

So, let’s get started!

Try an online Selenium Grid to run your browser Selenium automation testing scripts. Our cloud infrastructure has 3000+ desktop & mobile environments. Try for free!

What is the Playwright framework?

Built by the Microsoft team, Playwright is a framework for end-to-end testing and automation, which has slowly been building up popularity. You will see it at the top of most people’s favorite frameworks to work with.

The 2020 State of JavaScript survey among developers reveals that while Cypress adoption is on the upswing, Playwrights adoption remains very much in the early stages of development. However, the current trend of Playwright on GitHub shows the growing popularity of the Playwright framework (39.3k Star, 1.8k Fork, and 12.2k Active Users).

Not only is it versatile and easy to work with, but it has lightning-fast execution speeds and some great features that are unique to the Playwright framework, such as Trace Viewer and Test Generator.

Trace Viewer is a GUI tool that can be used to review Playwright traces after tests have been executed. If you want to experiment with it, you can set ‘trace’ to ‘on’ in your playwright.config.js:

After the test executions have been completed, there will be trace.zip files generated in your test-results folder:

There are a few different ways these reports can be viewed.

In your web browser through https://trace.playwright.dev/, where you can drag and drop the trace files.
By executing the following command in your CLI:

  npx playwright show-trace trace.zip

After following either of these processes, you will be presented with the Playwright Trace Viewer. Here you can dig deeper into the actions performed, how long they took to execute, parameters passed, network calls made, and any logs generated during execution.

You can also hover over the trace film strip at the top of the page to see a magnified image of each stage in the execution.

Test Generator is a browser tool that Playwright provides, which records the actions performed in the browser and generates the equivalent code. This is useful if you want to quickly draft some tests or upskill members of your team who are not so familiar with writing code.

Let’s run through a quick example. We are going to execute the below command, which launches Playwright codegen with the LambdaTest’s Selenium Playground.

    npx playwright codegen lambdatest.com/selenium-playground

When this is executed, two windows will launch. The first is your website which we can interact with, performing clicks, navigating, and entering data. The second is the Playwright Inspector, where our code will be generated dynamically.

On the first launch, you’ll see that the basic goto method for navigating the website has been generated.

page.goto("https://www.lambdatest.com/selenium-playground/")

If we interact with the page by selecting some of the checkboxes from the checkbox-demo example, you’ll see code gets generated dynamically.

One last thing worth mentioning is the ‘Target’ dropdown in the upper right of the Playwright Inspector. You can select from a list of different languages and export the code in whichever you require:

Watch this Playwright tutorial covers everything you need to get you up and running with the Microsoft Playwright framework with TypeScript.

Automate Cypress tests and perform browser automation cypress testing with LambdaTest. Our cloud infrastructure has 3000+ desktop & mobile environments. Try for free!

Why use the Playwright framework?

It’s an open-source framework relatively new to the market but is building up popularity fast. Microsoft maintains it and, as a result, receives regular updates and improvements. If we look at the number of downloads for similar frameworks which have been on the market for a while, you can see Playwright has burst onto the scene.

Releases

The Playwright team also provides their release notes in the form of video walkthroughs in addition to their standard release notes. This is something I haven’t seen from any of the other major frameworks and is a nice touch for gaining insight from the team building the product.

Here is a small snapshot from their most recent release, where they discuss their new implementation for Component testing.

Competitors

You may be trying to decide to migrate away from a well-established framework such as Selenium or on to Cypress test automation framework, which is also gaining popularity in the community.

My main reason for picking Playwright over others is how intuitive it is and the flexibility with which it can interact with the browser across multiple pages and domains. And lastly, execution speed. Speed is everything. If you can’t run your tests quickly and speed up your test cycle, you can’t deliver your product quickly. If you can’t deliver your product quickly, you’ll have a lot of unhappy stakeholders and customers.

This is a benchmark report that the ChecklyHQ team produced after performing in-depth execution speed monitoring on the major automation tools. As you can see, it pretty much speaks for itself. Playwright tops 2 out of 3 of the scenarios, closely followed by Puppeteer.

Execute & analyze Cypress test scripts online. Deploy quality builds faster with 40+ browser versions on Cypress Cloud.

Integrations

This is personally one of the most important factors for me when selecting a new tool or framework. Does it integrate well with our current architecture? The worst feeling is implementing something, only to realize later that it doesn’t have native integration, and we have to start building custom webhooks or plugins.

Thankfully the Playwright team has this covered. There are Docker images, so you can quickly execute tests in an isolated and controlled environment. And native CI tool integrations for the popular and top CI/CD tools, including GitHub Actions, Azure Pipelines, CircleCI, Jenkins, and GitLab.

They also provide support for your existing JavaScript test runners, such as Jest/Jasmine, AVA, and Mocha, which is useful if you are porting from an existing code base.

Lastly, there is direct integration with Selenium Grid. This is vital if you plan on running larger suites of tests at scale and require a grid environment to manage parallel execution.

Key features of the Playwright framework

Here are a few of the key features of Playwright and why you should check it out!

Support for cross-browser platforms built on Chromium, WebKit, and Firefox — which includes Chrome, Edge, Firefox, Opera, and Safari.
Support for cross-platform execution on Windows, Linux, and macOS.
Support for cross-language, including JavaScript, TypeScript, Python, Java, and .NET — write tests in the environment that suits you while still covering all areas and formats.
Auto-wait built-in, smart assertions that retry until the element is found, and test data tracing — keep track of logs, videos and screenshots easily.
Built with modern architecture and no restrictions — interact with multi-page, multi-tab websites like a real user, and tackle frames and browser events with ease.

Architecture: Playwright framework

We’ve covered some of the reasons why Playwright is great to work with on a feature and implementation level, but what is going on internally? What makes the test execution more stable and faster to execute?

So a good way to understand this is to compare it with Selenium — Selenium sends each command as a separate HTTP request and receives JSON responses. So every interaction, such as opening the browser, clicking an element, or sending keys in Selenium, is sent as a separate HTTP request.

As you can imagine, this results in slower execution as we wait for responses and introduces a layer of potential flakiness.

Playwright, on the other hand, communicates all requests through a single WebSocket connection, which stays in place until test execution is completed. This reduces the points of failure and allows commands to be sent quickly on a single connection.

This Cypress automation testing tutorial will help you learn the benefits of cypress test automation, and how to install Cypress and execute Cypress automation testing over scores of browsers and operating systems online.

Getting started with the Playwright Tutorial

Let’s cover some of the basic prerequisites that are needed before we get deeper into installation and setup.

Ensure you have NodeJS installed.
Install a code editor. We will be using Visual Studio Code.

Creating your first Playwright project

I’m going to cover a full introduction in this Playwright tutorial, starting with the initial commands all the way up to having a fully functioning automation project. There are a few different ways we can install Playwright.

Watch this video to learn how to run multiple projects in Playwright and execute them on the LambdaTest platform.

Installing Playwright using the VS Code extension

Follow the below steps to install Playwright using the VS Code extension:

1- Install VS Studio from the Visual Studio Marketplace.

2- Once this is installed, open the ‘Command palette’ under the ‘View’ tab, and type ‘install Playwright.’ Ensure you have created a folder for your project, which is currently open in VS Code, as this is where the new Playwright files will be generated.

3- After selecting this, you’ll be presented with the following dropdown options, where you can choose which browsers to install. You can also add GitHub Actions, which will generate a YAML build file for you.

4- When this is successfully installed, you should see the following message in the command line, which presents you with a few commands you can execute to get started:

And you’ll have the project created that looks something like this:

Watch this video to learn more about setting up the Playwright test automation framework:

Learn the advantages of Cypress automation, how to install Cypress, and how to carry out online cypress automation testing across a wide range of browsers and operating systems with the aid of this lesson on Cypress automation testing.

Installing the Playwright NPM package from the command line

This is fairly simple, and I’ll run through it step-by-step to explain what we are executing and what it is doing.

1- Run this command to install Playwright.

  npm init playwright@latest new-project

The ‘new-project’ parameter is the folder that will be created, containing all your project files. This can be anything, so feel free to use a name that suits your project type.

2- Once this is executed, you will be presented with multiple prompts which outline how you would like to configure the project. These can be selected with the arrow keys or keyboard selections. Once you have selected all options, the project will be initialized.

3- After following these steps, you’ll have a similar project structure as the VS Code extension workflow. The only difference is that the command line installation offers slightly more customization in choosing between JavaScript and TypeScript, and test folder location.

Some of the files and folder names may vary based on your selections during initialization, but here is a quick run-through of what we have.

workflows/playwright.yml: This is the GitHub Actions workflow yaml file. It is what will build and execute your tests from the GitHub platform.

    name: Playwright Tests
    on:
      push:
        branches: [ main, master ]
      pull_request:
        branches: [ main, master ]
    jobs:
      test:
        timeout-minutes: 60
        runs-on: ubuntu-latest
        steps:
        - uses: actions/checkout@v2
        - uses: actions/setup-node@v2
          with:
            node-version: '14.x'
        - name: Install dependencies
          run: npm ci
        - name: Install Playwright Browsers
          run: npx playwright install --with-deps
        - name: Run Playwright tests
          run: npx playwright test
        - uses: actions/upload-artifact@v2
          if: always()
          with:
            name: playwright-report
            path: playwright-report/
            retention-days: 30

Now, for a quick run-through of what it’s actually doing — In simple terms, ‘on’ any code push or merged pull request to the main/master branch, a build will be triggered. This build will run on a ubuntu-latest agent, it will checkout your code, install node and your npm dependencies. Then it will install Playwright framework, begin test execution, and upload a test execution report at the end.

node_modules: If you’ve worked with JavaScript before you’re probably very familiar with these, they are additional libraries which we can install in the project. In our case, you can see Playwright modules, which allow us to access additional functions from the Playwright library.

tests/example.spec.js: This is the example spec file that is generated when initializing Playwright. There are 75 tests in total covering various different scenarios. This is ideal for understanding the syntax and general approach to writing tests.

    // @ts-check
    const { test, expect } = require('@playwright/test');

    test.beforeEach(async ({ page }) => {
      await page.goto('https://demo.playwright.dev/todomvc');
    });

    const TODO_ITEMS = [
      'buy some cheese',
      'feed the cat',
      'book a doctors appointment'
    ];


    test.describe('New Todo', () => {
      test('should allow me to add todo items', async ({ page }) => {
        // Create 1st todo.
        await page.locator('.new-todo').fill(TODO_ITEMS[0]);
        await page.locator('.new-todo').press('Enter');

        // Make sure the list only has one todo item.
        await expect(page.locator('.view label')).toHaveText([
          TODO_ITEMS[0]
        ]);

.gitignore: This is a common Git file, which will exclude folders that we do not want to commit to our remote repository. They will be generated dynamically during the build and test execution.

package-lock.json/package.json: The package.json file is generated during the initialization of the project and contains information regarding your project, entry points for test execution, custom scripts, and package dependencies. The package-lock.json plays a slightly different role. It tracks the exact version of every package installed. For more detailed information on why these files are important, refer to the official NPM package.json and package-lock.json docs.
Playwright.config.js: This file contains all the configuration required for your Playwright project. You can configure timeouts, parallelism, retries, reporters, and browsers, just as a brief example! It is open to tons of customization and adjustment to meet your test suite’s requirements. You can find the full configuration docs here: https://playwright.dev/docs/test-configuration.

Subscribe to the LambdaTest YouTube Channel and stay updated with the latest playwright tutorial also discover tutorials around topics like automated browser testing, Cypress E2E testing, mobile app testing, and more.

Running your first Playwright test

Let’s run some tests to make sure everything is working. Execute the following in the terminal:

npx playwright test

This will run headless, so you should see activity in the terminal as tests are executed:

We have 75 passing tests, executed in 42 seconds. Good stuff!

If you want to look into the tests which were just run, you can open the example.spec.js. The test cases are marked by the syntax ‘test.describe’, and at the top of the file, you can see required packages, steps executed before each test, and some list data used within the tests.

Workers

There are a few things also to note — we have 8 workers being used. This means 8 different processes running in parallel to execute our tests. Refer to the Playwright’s official docs for more detailed information on parallelism and sharding.

By default, the number of workers being used will always be 8 (undefined), and when running in a CI environment, it will be 1. You can change these values in your playwright.config.js to run more or fewer tests in parallel, depending on your hardware capabilities. This is worth experimenting with in small increments to get a feel of what best suits your needs while maintaining a fast test execution time.

Reports

Another thing you may have noticed after your test execution is this snippet:

//To open last HTML report run:

  npx playwright show-report

If you execute that command, a browser window will launch on localhost, which looks something like this:

It gives you a nice report of your most recent test execution, with information regarding test outcomes, test cases, browsers executed on and test execution times.

Creating a basic Playwright test

Now that we’ve executed some basic tests let’s try adding some of our own! Add a file to your tests folder called ‘form.spec.js’

We need to add a line to the start of the file to access the Playwright module and test functions. From there, we define our test case ‘input form data’.

We are creating an instance of ‘page’ to access the most common Playwright methods. The first one we will be using is ‘goto’, which will navigate us to the defining url.

const { test } = require('@playwright/test');

test('input form data', async ({ page }) => {
  await page.goto('https://www.lambdatest.com/selenium-playground/input-form-demo');
});

In the terminal, navigate to the tests folder and execute the below command.

npx playwright test form.spec.js

The output should look something like this:

Now we know that our new test can execute successfully, let’s add a bit more complexity and an assertion, to ensure our test will catch actual issues.

This is what the page looks like on LambdaTest’s Selenium Playground:

We are going to enter data into all of the fields. The code will look something like this:

      await page.locator('[placeholder="Name"]').fill('Mr Test');
      await page.locator('[placeholder="Email"]').fill('randomemail@test.com');
      await page.locator('[placeholder="Password"]').fill('Abc123');
      await page.locator('[placeholder="Company"]').fill('Fake company');
      await page.locator('[placeholder="Website"]').fill('Fake website');
      await page.locator('select[name="country"]').selectOption('GB');
      await page.locator('[placeholder="City"]').fill('London');
      await page.locator('[placeholder="Address 1"]').fill('123 New road');
      await page.locator('[placeholder="Address 2"]').fill('New street');
      await page.locator('[placeholder="State"]').fill('New state');
      await page.locator('[placeholder="Zip code"]').fill('abc123');
      await page.locator('button:has-text("Submit")').click();

As you can see, we are using the page.locator method, followed by the element locator, and we are using this to fill the empty fields and click the submit button.

If we execute this test as it is, it will still pass. We need an assertion of some kind to verify the success criteria of the test, which will fail if it is not met.

Following submission of the form, the following page is displayed with a confirmation message:

We will assert that the confirmation message element is visible to the user, with the following code:

  const locator = page.locator('text=Thanks for contacting us, we will get back to you shortly.');
  await expect(locator).toBeVisible();

You can execute this test, and we will once again see it passes successfully. Let’s change the assertion to something different and make sure it’s a valid test.

    const locator = page.locator('text=Welcome back');
      await expect(locator).toBeVisible();

As we can see after running this test again, it is now failing at line 20, where the expected locator is not displayed:

This terminal logging is very helpful for quickly finding out where and why the test is failing. Let’s revert the change and run the full test.

Nice! Full form submission and an assertion in 4 seconds.

Let’s run the same test across 3 different browsers and take a look at the report. Add –browser=all to the end of your command in the terminal.

  npx playwright test form.spec.js --browser=all

And if we use the command we learned earlier, we can view the html report:

   npx playwright show-report

In this article of the Playwright tutorial series, we have seen how to set up the Playwright framework for the end-to-end test automation. So far, we have learned how to execute a simple test using the Playwright test automation framework.

Though Playwright comes with a lot of features to leverage, its true potential can be evaluated only over a cloud-based grid. In the upcoming blogs of this Playwright tutorial series, we will learn to run Playwright tests on a cloud grid like LambdaTest.

Cloud testing platforms like LambdaTest allow you to perform cross browser testing on an online browser farm of 50+ browsers and browser versions of Chrome, Chromium, Microsoft Edge, Mozilla Firefox, and even Webkit. You can even run your Playwright test scripts in parallel and cut down your test execution time by multiple folds.

Watch this video to learn more about handle user inputs, buttons, checkboxes, and other UI elements in Playwright with the help of live examples:

Are you using Playwright for automation testing? Run your playwright test scripts instantly on 50+ browser/OS combinations using the LambdaTest cloud. Sign up for free!

VS Code extensions for Playwright

Now, before we wrap up, I’d like to run through some of the awesome functionality you get from installing the Playwright test extension in VS Code. As a reminder, you can find that here, after opening the extensions tab:

Now, you’ll notice we have a Testing icon on the lower left of the screenshot below:

From here, we can see all the tests in the project. Not only that, but it also opens up some very nicely integrated functionality for us to use:

Test Execution We can execute tests by selecting the ‘Run test’ icon, and as the test progresses, the line of code being executed is highlighted.

In addition to that, you will also notice at the end of each line is the execution time in milliseconds. I personally love this kind of data, as it allows you to tweak and optimize your code based on the information you can easily access.

Debug Tests If we set a breakpoint in our test by selecting to the left of the line numbers and run the test in debug mode, the test execution will stop at this point.

In this example, I’ve set a breakpoint at the company field, so we can pause here and see exactly what the test is doing.

On a side note, to make your life of testing easy and fuss-free while debugging, you can try the LT Debug Chrome extension.

Real-Time Code Editing Now, here is an additional feature I find amazing, mostly due to how it’s embedded in the test execution. We can edit the element in the code in real-time, and it will update in the browser window. For example, I’ve changed the locator from ‘Company’ to ‘Password,’ and we can see it’s moved the highlighted locator:

Record Lastly is the ‘Record’ option. This behaves similar to ‘codegen,’ which we experimented with earlier in this blog. When you select ‘Record,’ a window will be launched, and a spec file will be generated:

As we start to navigate and interact with the page, code will be generated in real-time:

As mentioned previously, this is great for quickly structuring a test or training more junior members of your team, they can piece together how interactions with the page align with the written code.

Watch this video to learn about some exciting features offered by Playwright, like recording tests, taking screenshots of tests, auto-wait mechanism, and much more.

Conclusion

Playwright is an incredibly versatile framework with features that are just plain enjoyable to use, which is something special when put side-by-side with other frameworks in the industry, which can sometimes be more of a chore.

It makes writing automation tests very simple, and you’ll be building up large suites of tests in a fraction of the time you would with others. Also, the entry bar is kept low, so it won’t be intimidating if you introduce it to a new team.

I hope you gained some insight from this Playwright tutorial, and may it be top of your favorite automation frameworks to use in the future.

How To Run Your First Playwright Test On Cloud

GaryParker12 — Mon, 05 Dec 2022 13:42:17 +0000

One of the biggest problems I’ve faced when building a test suite is not the writing of the tests but the execution. How can I execute 100s or 1000s of tests in parallel?If I try that on my local machine, it would probably catch fire — so we need a remote environment to send these to.

Selenium Grid has been the gold standard solution for a long time, it allows you to distribute tests across multiple machines, and at present, it is fairly easy to manage. The second problem I’ve faced is where do we get these machines? Do we use the hardware we own, or do we purchase VMs from a cloud provider — both require quite a bit of maintenance and configuration.

The solution a lot of organizations end up moving towards is some form of Cloud Grid facilitating cloud testing. It’s an environment where you can send your tests and not worry about what is happening in the background. Your tests are distributed in parallel, they execute the necessary commands, and you’re given test results. It’s much more accessible for the user and requires little to no maintenance.

We will run a test suite locally on a basic Selenium Grid configuration to understand how it works and its limitations. We will then execute tests remotely on a Cloud Grid, with a higher level of parallelism — not only in test cases but also browser and operating system types.

On a global scale, users interact with a wider range of devices and platforms daily, and this ability to run automated tests at scale becomes increasingly important.

This Playwright tutorial will look at writing and running your first Playwright test on a cloud grid like LambdaTest.

Before we begin, I’m going to give an overview of what we are aiming to achieve in this tutorial on Playwright testing:

Build a simple test suite
Execute tests
On your local machine
On Selenium Grid
On a Cloud Grid environment

In this article, we look at what is regression testing, its importance and types, and how to perform it.

Building a Playwright test suite

We will be using the Playwright framework to build our tests. Playwright is a relatively new framework but is growing in popularity as its powerful features continue to prove valuable for application developers. Microsoft contributes many of these features as Playwright gets regular updates and improvements. Playwright has overtaken many similar automation testing frameworks in terms of downloads due to its powerful features and overall appeal to users.

Before we get deeper into installation and setup, here are some basic prerequisites.

Ensure you have NodeJS installed.
Install a code editor. I will be using Visual Studio Code.

If you need to get up to speed with installation and setup, follow my earlier blog on getting started with the Playwright framework.

For this tutorial on running your first Playwright test, we will be writing tests for the LambdaTest eCommerce Playground with dummy data and content — perfect for experimenting with test automation.

Test approach for writing your first Playwright test

Before we jump into writing the tests for Playwright end to end testing, I’ll give a brief overview of the approach and end product. The test cases I’ve selected are quite common journeys, and there is a good chance you’ve written similar tests or had to consider similar scenarios, regardless of the product background.

The first is ‘ADD TO CART,’ the site’s core functionality as a user. We should be able to select an item, add it to our cart and progress to the checkout journey. Any discrepancies in product items or selection along the way should be caught by our test.
The second combines ‘SEARCH’ and ‘FILTERING.’ We should be able to search for a particular item or category of items and then filter the list returned. The common filtering techniques could be by most popular, lowest price, or most recently added.

Once both tests are added, we will expand upon these user journeys by adding slight variations. This is a good technique to increase test coverage while reusing existing code — we add value to the test suite with minimal effort. The final project structure should look like this:

Watch this Playwright tutorial that covers everything you need to get you up and running with the Microsoft Playwright framework with TypeScript.

Want to know more about how to perform regression test? Let’s have a look at the detailed guide of Regression Testing.

Writing your first Playwright test

This is a fairly standard user journey, I’d like to choose an item to purchase, add it to my cart, and the item should be visible when I go to checkout.

In the playwright.config.js, I’ve defined the eCommerce playground base URL, so all of our tests will start from here.

 use: {
        /* Maximum time each action such as `click()` can take. Defaults to 0 (no limit). */
        actionTimeout: 0,
        /* Base URL to use in actions like `await page.goto('/')`. */
        // baseURL: 'http://localhost:3000',

        /* Collect trace when retrying the failed test. See https://playwright.dev/docs/trace-viewer */
        trace: 'on-first-retry',
        baseURL: 'https://ecommerce-playground.lambdatest.io'
      },

And in the lambdatest-setup.js, which is referenced in our test files, we are defining our test platform capabilities, which will be used for local and remote execution.

   // 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 Build - Full suite',
         'name': 'Playwright Test',
         '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': '', // country code can be fetched from https://www.lambdatest.com/capabilities-generator/
       }
     }

This is the complete test file for add-to-cart.spec.js, I’ll walk through each step and explain why we have taken this approach.

// @ts-check
const { test } = require('../../lambdatest-setup')
const { expect } = require('@playwright/test')

test.describe('Add to cart', () => {
  test('Add to cart', async ({ page }) => {

    // Navigate to base url
    await page.goto('https://ecommerce-playground.lambdatest.io')

    // Click Shop by Category
    await page.locator('text=Shop by Category').click();

    // Click Laptops & Notebooks
    await page.locator('text=Laptops & Notebooks').click();

    // Hover over product
    await page.locator('text=Add to Cart Add to Wish List HTC Touch HD $146.00 HTC Touch - in High Definition').hover()

    // Wait for element
    await expect(page.locator('text=Add to Cart Add to Wish List HTC Touch HD $146.00 HTC Touch - in High Definition >> button >> nth=0')).toBeVisible()

    await page.waitForTimeout(2000)

    // Click add to cart
    await page.locator('text=Add to Cart Add to Wish List HTC Touch HD $146.00 HTC Touch - in High Definition >> button').first().click()

    // Click view cart
    await page.locator('text=View Cart').click()

    // Assert correct product added to cart
    await expect(page.locator('#content >> text=HTC Touch HD')).toBeVisible()
    })
  });

The completed test suite we will be referencing is on GitHub if you want to follow along.

There is a simple goto navigation, which extends upon our base URL. This is useful if we navigate to sub-pages within the website, as we won’t need to type the full base URL every time.

        // Navigate to base url
          await page.goto('/')

This will launch a page that looks like this.

Now, there are a few different ways to browse products on the page. There is ‘Shop by Category, ’ which opens a sub-menu, the search bar at the top, the main banners, and additional product icons as we navigate further down the page.

For our first Playwright test, we will use the ‘Shop by Category’ menu to find our product. Firstly we need to click the menu, so it expands. For readability, I prefer to use text as our identifier — even if there are multiple elements with the same name, it’s still fairly easy to drill down further.

Note — To find the elements, I like to use a mix of Playwright Codegen and also manually inspect the elements in DevTools when needed.

         // Click Shop by Category
          await page.locator('text=Shop by Category').click();

Now that we’ve expanded the menu, we have to decide which category we want to purchase an item from. I think a laptop would be good! Let’s use the same text locator strategy as before.

      // Click Laptops & Notebooks
          await page.locator('text=Laptops & Notebooks').click();

Following that action, we’ve landed on the Laptops & Notebooks product page — ignore the images that are not Laptops or Notebooks. It’s just placeholder content for testing purposes.

If we hover over an item in the gallery, we will notice a menu presenting a few options.

We are interested in the first option, so we will need to hover over the product and click the first icon — this will add the product to our cart.

     // Hover over product
      await page.locator('text=Add to Cart Add to List HTC Touch HD $146.00 HTC Touch - in High Definition').hover()

      // Wait for element
      await expect(page.locator('text=Add to Cart Add to Wish List HTC Touch HD $146.00 HTC Touch - in High Definition >> button >> nth=0')).toBeVisible()

      // Click add to cart
      await page.locator('text=Add to Cart Add to Wish List HTC Touch HD $146.00 HTC Touch - in High Definition >> button').first().click()

Hovering over the product is fairly simple. We provide the image/product locator, followed by the .hover() action. I used the text locator in this instance as it was unique.

This screenshot is taken during the Playwright Codegen recording.

For the wait to be visible and click, I had to extend the locator slightly. We used two different approaches so that you can see different solutions to the same problem.

In the wait for element step, we have added to the locator path with >> nth=0, which is getting the 0 position element, which in this case is the first of the four buttons.

In the click add to cart step, we are using almost the same locator, except this time instead of adding to the path, we are using the .first method, so click the first element of the four available.

This is a breakdown of our approach in this tutorial on running your first Playwright test:

Identify product locator.
Hover over the product.
Identify the actionable element we want to select.
Drill down into the group of elements.
Make use of the Playwright index options and nth locator options.

Both approaches have valid applications. The second may be better for reusability if you have a list of elements — in which case you will also be able to use locator.nth(index), in addition to .first() and .last().

If we execute the test until this point, you should see a popup appear in the upper right corner of the screen. It presents us with two options, view cart, and checkout.

The goal of this test is just to check the product has been correctly added to the cart. So we will be clicking the button which says ‘View Cart’. In some cases, waiting for the popup to appear may also be necessary, in which case we can do something like this.

     // Wait for element
        await expect(page.locator(‘.toast-header')).toBeVisible()

      // Click view cart
      await page.locator('text=View Cart').click()

The last step of the journey is on the shopping cart page. We want to be confident that every time a user selects ‘Add to Cart’ on a product, it appears on the shopping cart page.

The product name is a good indicator that not only has an item been added to the cart, but it is also the correct product we selected earlier. So we will use a locator path that contains the product name and verify it is visible on the page.

     // Assert correct product added to cart
      await expect(page.locator('#content >> text=HTC Touch HD')).toBeVisible()

That’s it — a very simple user journey, covering a few different types of interactions and verifications with the web page. Let’s run the test!

This is the script I’m using to execute the laptop-specific test in the headed mode so we can see what is going on. In the terminal, you just need to type: npm run test.

     "scripts": {
        "test": "npx playwright test tests/add-to-cart/add-to-cart-laptop.spec.js --headed"
      },

Now we have a base test to work with, we can create some variations on this — and then start to execute a larger number of tests.

Perform browser automation testing on the most powerful cloud infrastructure. Leverage LambdaTest automation testing for faster, reliable and scalable experience on cloud.

Expanding the Playwright test suite

There are many different categories and products on the eCommerce website, so we can add a few tests to expand the test coverage. These were pretty easy to create, as they were minor locator updates.

In this tutorial on running your first Playwright test, we have duplicated the files and locators for ease of use, but ideally, we should use an approach, such as the Page Object Model (POM), to maintain this. It increases reusability, minimizes code duplication, and makes general maintenance much easier.

Here’s an example of the added code and the spec file.

  // Hover over product
  await page.locator('text=Add to Cart Add to Wish List Nikon D300 $98.00 Engineered with pro-level feature').hover()

  // Wait for element
  await expect(page.locator('text=Add to Cart Add to Wish List Nikon D300 $98.00 Engineered with pro-level feature >> button >> nth=0')).toBeVisible()

  // Click add to cart
  await page.locator('text=Add to Cart Add to Wish List Nikon D300 $98.00 Engineered with pro-level feature >> button').first().click()

We can execute these Playwright tests locally and still see fairly fast execution times. I’ve modified our npm run test script to include the whole Playwright test folder:

      "scripts": {
        "test": "npx playwright test tests/add-to-cart/ --headed"
      },

There are many elements to interact with on the website, so let’s add a test to search for an item, filter by the most popular items returned, and add the most popular ones to our cart. There is some code we will reuse, and in the future, it would be good to create page objects or helper classes instead of copying/pasting our code.

I’ve used the placeholder text locator for that field, and we are filling it with the text ‘ipod’. We are then clicking the search button to return our results.

      // Fill [placeholder="Search For Products"]
      await page.locator('[placeholder="Search For Products"]').first().fill('ipod');

      // Click text=Search
      await page.locator('text=Search').click()

We need to select ‘Popular’ from the ‘Sort by’ dropdown on the search results page. We can do that by text or index. For this example, I’ve used the index of the dropdown item we are looking for.

      // Click sort by 'Popular'
      await page.locator('#input-sort-212464').selectOption({index: 2})

This will reorder the items for us, and all we need to do is select the first product returned to the list and add it to our cart.

    // Wait for element
      await expect(page.locator('.product-action > button').first()).toBeVisible()

      // Click add to cart
      await page.locator('.product-action > button').first().click()

Done! Nice, so now we have a new test from which we can create iterations. In total, I’ve created 6 tests. Let’s run them in parallel and see how they perform.

When running 6 tests, I started to see intermittent failures, despite adding waits and timeouts — this is where we start approaching the limits of a single machine for test execution and need to look towards a distributed solution.

If you’ve worked with automation in any form, I’m sure you’ve seen a similar diagram.

This is the basic premise of Selenium Grid — we send tests from our ‘client’ machine to our ‘hub’, and the ‘hub’ distributes the tests out to our ‘nodes.’ In this example if we had a suite of 9 tests, and each node had 3 Chrome instances available, we would see 3 tests executed on each node in parallel.

We will set Selenium Grid up on our local machine — it’s not following the intended architecture of Selenium Grid, as we won’t be creating separate VMs for our nodes. Still, it should give you an understanding of how it works and its benefits.

Setup:

Download Java (you may need to set the environment variable path).
Download Selenium Server (Grid).
Download the latest stable Chromedriver version.
Download the latest stable Geckodriver version.
Set the PATH environment variable for both drivers (folder location).

Accelerate your release velocity with blazing fast test automation on cloud!

Playwright test execution

Run the following command from your download location for Selenium Server (Grid). The version number may need to be changed if a newer version has been released.

    java -jar selenium-server-4.3.0.jar standalone

In the terminal, you should see the following:

It has detected 16 available processors and 2 drivers, and as a result, has created 16 instances of Chrome and Firefox. The grid has been started at http://localhost:4444/. If we navigate that URL, we should see the following:

Now, we can send some tests to the grid. If we open a Git bash terminal and run the following command (replace the localhost value):

    SELENIUM_REMOTE_URL=http://localhost:4444/wd/hub npx playwright test

Playwright will execute its tests on the Selenium Grid remote URL, and we should be able to see 6 sessions actively running.

That’s basically all we need to know about how to run tests on Selenium Grid at a basic level — the more involved setups involve multiple VMs, and there are many useful Docker images/compose file templates that can be used to spin up the grid environment.

Once we start scaling out, we can run larger amounts of tests concurrently and at a faster speed — limited only by hardware costs and management.

Run automated browser testing on the most robust cloud infrastructure. Leverage LambdaTest automated testing for a more responsive, dependable, and scalable cloud experience.

Running your first Playwright test on cloud grid

Now to take our test suite and run it on a larger scale — more platforms and more browsers. We will be using the LambdaTest Cloud Grid for these examples, so you’ll need a few things configured before we begin.

Cloud testing platforms like LambdaTest help you perform cross browser testing at scale. It offers an online browser farm of 50+ browsers and browser versions of Chrome, Chromium, Microsoft Edge, Mozilla Firefox, and even Webkit to run your first Playwright script.

Subscribe to the LambdaTest YouTube Channel, stay updated with the latest playwright tutorial, and discover tutorials around topics like automated browser testing, Cypress E2E testing, mobile app testing, and more.

Prerequisites to run your first Playwright test on cloud

We will use a new configuration file that references LT_USERNAME AND LT_ACCESS_KEY environment variables.

       'user': process.env.LT_USERNAME,
        'accessKey': process.env.LT_ACCESS_KEY

You can find this information under Dashboard, Automation, or User settings. Copy the values and set them as your local machines environment variables.

Playwright test configuration on cloud

In our playwright.config.js, we have now set a few new projects:

projects: [
    {
      name: 'chrome:latest:MacOS Catalina@lambdatest',
      use: {
        viewport: { width: 1920, height: 1080 }
      }
    },
    {
      name: 'chrome:latest:Windows 10@lambdatest',
      use: {
        viewport: { width: 1920, height: 1080 }
      }
    },
    {
      name: 'MicrosoftEdge:90:Windows 10@lambdatest',
      use: {
        viewport: { width: 1920, height: 1080 }
      }
    },
    {
      name: 'pw-firefox:latest:Windows 10@lambdatest',
      use: {
        viewport: { width: 1920, height: 1080 }
      }
    },
    {
      name: 'pw-webkit:latest:MacOS Catalina@lambdatest',
      use: {
        viewport: { width: 1920, height: 1080 }
      }
    }
  ]

There is logic in the lambdatest-setup.js file, which runs our tests based on the following format: browserName:browserVersion:platform (separate by colons). You can edit and change these values or add new configurations if needed. You can also modify the viewport size and device emulation values.

Which are the most wanted automated testing tools that have climbed the top of the ladder so far? Let’s take a look.

Playwright test execution on cloud

With the variables and project configurations in place, we are ready to run the tests. Run the npm run test, and you should see tests executing in the terminal.

You should see 30 tests running this time, as our 6 tests are run against 5 different configurations. Some tests are passing across our chrome set up, which we would expect as this is what we tested against locally earlier on. But you’ll also notice a lot of red — as platforms we haven’t tested give unexpected results.

This is good news — our tests have caught an issue with our website or our code. After looking into the test results and logs, one of the issues becomes very clear. We are testing against a mobile view, where the layout and elements have changed — for example, we no longer have the main menu bar, which has collapsed to a hamburger menu.

For the short term, we can change the viewport to match the others — so we still have desktop coverage against the Microsoft Edge platform. In the long term, we would need to rewrite the test logic to accommodate the mobile view or create a separate suite of tests for that platform.

The last issue we have is with WebKit — initially, we had it running on Windows, so I tried on macOS to see if there were compatibility issues, but the issue occurred on both. The tests could not hover over the products and click add to cart. This is potentially a genuine issue, and for this scenario, we would manually test the website on that platform and try to debug the issue.

Let’s look at our local setup and how it compares to the Cloud Grid.

Local Grid — 6 tests run on Chrome Windows — with the potential to run Firefox, Edge, and WebKit. Additional configuration is required to scale and increase platform coverage.

Cloud Grid — 30 tests run on Windows and Mac platforms across Chrome, Firefox, Edge, and WebKit. Not only do we have an incredible amount of test coverage out of the box, but the configuration was minimal, and the maintenance is zero — we just have to worry about building and increasing the test suite coverage.

If you are a developer, this certification is the perfect measure of your expertise as a Playwright automation tester in performing end-to-end testing for modern web applications.

Conclusion

It’s no longer good enough to run manual and automated tests on a single most popular configuration, i.e., Chrome with Windows or Safari with Mac. We need to be able to run a large number of tests, quickly and at scale, across a matrix of browsers, platforms, and resolutions.

With a Cloud Grid platform, a lot of the complexity is taken away from the user, so they can focus on what matters — writing robust and effective automated tests.