Playwright Tutorial: Getting Started With Playwright Framework

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.

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.

Run your Playwright tests with AWS marketplace directly on cloud.

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.

Note: Run Automated Playwright Tests Online. Try TestMu AI Now!

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 TestMu AI platform.

Installing Playwright using the VS Code extension

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

• Install VS Studio from the Visual Studio Marketplace.

• 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.

• 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.

• 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:

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.

• Run this command to install Playwright.

npm init playwright@latest new-project

• 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.

• 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.

• 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.

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

Subscribe to the TestMu AI 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.

Note: Run your Playwright test scripts instantly on 50+ browser and OS combinations. Try TestMu AI Now!

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 TestMu AI’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('[email protected]');
  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 TestMu AI.

Cloud testing platforms like TestMu AI 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: