DEV Community: Max Schmitt

Running Playwright Codegen with existing Chromium Profiles

Max Schmitt — Thu, 19 Sep 2024 10:16:53 +0000

Playwright is a powerful tool for browser automation, and one of its lesser-known features is the ability to run tests using existing browser profiles. This can be incredibly useful when you need to test scenarios that require specific browser configurations, extensions, or saved login states. In this article, we'll explore how to use Playwright to launch Microsoft Edge or Google Chrome with custom profiles.

Setting Up the Environment

Before we dive into the code, make sure you have Playwright installed in your project:

npm install @playwright/test

Create a file named codegen.mjs in your project directory. We'll use this file to run our Playwright scripts.

Launching a Browser with the Default Profile

Let's start with a basic example that launches Microsoft Edge with the default profile:

import { chromium } from '@playwright/test';

(async () => {
  const context = await chromium.launchPersistentContext('C:\\Users\\YourUsername\\AppData\\Local\\Microsoft\\Edge\\User Data', {
    headless: false,
    channel: 'msedge',
  });
  // For macOS, use:
  // Microsoft Edge: '/Users/YourUsername/Library/Application Support/Microsoft Edge'
  // Google Chrome:  '/Users/YourUsername/Library/Application Support/Google/Chrome'

  const page = context.pages()[0];

  await page.pause(); // This will open Codegen if needed

  await context.close();
})();

This script does the following:

Imports the chromium object from Playwright.
Launches a persistent context using the default Edge profile.
Gets the first page from the context.
Pauses the execution, which opens the Playwright Inspector (Codegen) for interactive debugging.
Closes the context when done.

Using a Specific Browser Profile

To use a different profile, we need to add the --profile-directory argument. The profile directory might be different to the profile
name. In order to find out the profile directory, you can navigate to chrome://version in the browser and look for the Profile Path field. The last part of the path is the profile directory name.

import { chromium } from '@playwright/test';

(async () => {
  // Setup
  const context = await chromium.launchPersistentContext('C:\\Users\\YourUsername\\AppData\\Local\\Microsoft\\Edge\\User Data', {
    headless: false,
    channel: 'msedge',
    args: [`--profile-directory=Profile 2`]
  });
  // For macOS, use:
  // Microsoft Edge: '/Users/YourUsername/Library/Application Support/Microsoft Edge'
  // Google Chrome:  '/Users/YourUsername/Library/Application Support/Google/Chrome'

  const page = context.pages()[0];

  await page.pause();

  await context.close();
})();

The key difference here is the args option in the launchPersistentContext method, which specifies the profile directory to use.

Remember to replace YourUsername with your actual username on your system.

Using Playwright Codegen

In both examples, we've included await page.pause();. This line opens the Playwright Inspector, also known as Codegen. This tool allows you to:

Inspect the page structure
Record actions and generate code
Step through your script
Modify and rerun parts of your script

Running the Script

To run the script, use the following command in your terminal:

node codegen.mjs

Important Notes

Profile Availability: Ensure that the browser profile you're trying to use isn't already open. If it is, Playwright won't be able to launch it.
Profile Names: The profile directory names (e.g., "Profile 2") should match exactly with the names in your browser's profile directory.
Browser Channel: In our examples, we've used channel: 'msedge' for Microsoft Edge. For Google Chrome, you would use channel: 'chrome'. Make sure to adjust the profile path accordingly.
Path Accuracy: Double-check that the path to your browser's user data directory is correct. It may vary depending on your operating system and browser version.

Useful links

Implementing Microsoft Entra Certificate-Based Authentication with Playwright

Max Schmitt — Wed, 18 Sep 2024 13:33:06 +0000

Introduction to Certificate-Based Authentication (CBA)

Microsoft recently announced (July 2024) support for certificate-based authentication (CBA) for Microsoft Entra. CBA is a phishing-resistant, passwordless, and convenient way to authenticate users with X.509 certificates without relying on passwords. With the recent v1.46 release, Playwright now supports the CBA method for authenticating with Entra.

TLS Client Certificates and Their Role in CBA

TLS client certificates are digital credentials that authenticate clients to servers in secure connections. They contain the client's public key, are signed by trusted authorities, and enable mutual authentication. These certificates enhance security by verifying client identities, preventing unauthorized access to sensitive resources in various IT environments.

If no client certificate is available, your browser will display a prompt like this:

Implementing CBA with Playwright

Step 1: Obtain the certificates

If the certificate files are not yet available on the client, we recommend defining base fixtures that will fetch the certificates in every worker process. The certificates will then remain in memory. See here for all available options for clientCertificates (e.g., if you are using PEM instead of PKCS#12).



import { DefaultAzureCredential } from '@azure/identity';
import { SecretClient } from '@azure/keyvault-secrets';
import { test as base } from '@playwright/test'

// DefaultAzureCredential automatically detects and uses the most appropriate authentication method,
// including environment variables, managed identities, and OIDC tokens from GitHub Actions.
// We recommend OIDC logins via e.g. azure/login:
// https://github.com/Azure/login/?tab=readme-ov-file#login-with-openid-connect-oidc-recommended
const credential = new DefaultAzureCredential();

const vaultName = '<YOUR KEYVAULT NAME>';
const KEYVAULT_URI = `https://${vaultName}.vault.azure.net`;
const secretName = '<YOUR SECRET>';

const secretClient = new SecretClient(KEYVAULT_URI, credential);

export const test = base.extend({
  clientCertificates: async ({ }, use) => {
    const certificateSecret = await secretClient.getSecret(secretName);
    await use([
      {
        origin: 'https://certauth.login.microsoftonline.com',

        // Alternatively, if you use e.g. PPE, it's: https://certauth.login.windows-ppe.net
        pfx: Buffer.from(certificateSecret.value!, 'base64'),

        // You might need to provide your passphrase here:
        // passphrase: process.env.SECRET_PASSPHRASE
      }
    ]);
  }
});

export { expect } from '@playwright/test'

Step 2: Update your test @playwright/test imports



-import { test, expect } from '@playwright/test';
+import { test, expect } from './baseTest';

Step 3: Log in inside a test



import { test, expect } from './baseTest';

test('is able to login', async ({ page }) => {
  await page.goto('https://your-application.com/login');
  // Your login logic here
  await page.getByRole('textbox', { name: 'Email' }).fill('example@foo.com');
  await page.getByRole('button', { name: 'Sign in' }).click();
});

You can also provide client certificates as a parameter of browser.newContext() and apiRequest.newContext().

Troubleshooting

To debug which network requests are being made, you can set the DEBUG=pw:client-certificates environment variable. This will print all the connections that are being established.

It's a known issue that the authentication does not work if the --disable-web-security argument is passed to Chromium.

Useful links

Troubleshoot your Playwright or Puppeteer tests and find the root cause for failing tests

Max Schmitt — Thu, 22 Oct 2020 13:19:26 +0000

Introduction

End-to-end tests are important to ensure that there are no regressions in the functionality of a web application over time. As part of a modern development workflow, we would want to run them automatically in the CI before every code merge to the codebase (e.g. GitHub pull request) and deploy.

An end-to-end test is usually a programmatically executed real user flow in the app, typically executed in the cloud on headless browser instances as part of CI process. End-to-end tests help us to keep our app working and the users satisfied.

On this blog post, we will focus on Playwright, a Node.js library which makes it possible to automate Chromium, Firefox, and WebKit with a single API and Root Cause, a library to help us troubleshoot end-to-end tests.

Debugging tests

One of the challenges of creating, running and maintaining end-to-end tests is that once changes are implemented, tests might fail and finding the root cause of the failure can be difficult. For this scenario, Testim has created an Open Source tool called Root Cause, that makes it easy to debug and analyze failures with a central interface even when they fail on the CI. It focuses on the following core needs:

Visualize to troubleshoot - Show screenshots and highlight used elements
Store locally or in the cloud - Analyse the results locally or on a central hosted interface
Drill-down with data you need - View console logs or the network traffic as HAR files
Test run reporting - Access to filter and search functionality

Integrations

Writing tests in the JavaScript or TypeScript ecosystem is mostly done using the Jest test runner, it provides a solid foundation for finding and running tests and has integrated helper methods to assert values against expected values. The Root Cause project provides integration for common test runners such as Jest and Mocha.

For Jest, you only have to install it with npm install @testim/root-cause-jest from NPM and adjust your main Jest configuration, for a full setup guide, see the official documentation on help.testim.io.

Once it's successfully integrated you can continue as normal with Playwright. So you can interact with pages to navigate to sites, click on elements, or call your custom logic. Root Cause internally will then record it in the background to provide a first-class debug experience if they are failing.

Managing results

The results which Root Cause is recording gets saved automatically on your disk. You can view them by running npx root-cause ls to list them and npx root-cause show <result-id> to view a selected report. This will open the interface to see all the tests which were running, stack traces if there are failing tests, and additional metadata for network traffic, pages, or console as you can see here:

Root Cause Cloud

Root Cause viewer is also available as a hosted solution which gives you the flexibility of uploading your test results from your CI provider (e.g. GitHub Actions, or Travis CI) to them and act as a central interface of your project. This automatically will analyze them if multiple are failing for the same reason or give you statistically-based insights.

Summary

Root Cause is a great way to simplify troubleshooting your Playwright tests. You can get started using the OSS version on GitHub. For more information on the hosted Root Cause solution on Testim.io which can be used for free for most use cases. They also provide an example showcase repository on GitHub which demonstrates other integrations like with Mocha.

The Open Source project is hosted on GitHub: github.com/testimio/root-cause.

Monitoring with Playwright on Checkly made easy

Max Schmitt — Thu, 24 Sep 2020 12:41:33 +0000

Introduction

Nowadays, catching issues with your service early on is paramount to ensuring that your SLAs are being met. For this reason, having a reliable and feature-rich active monitoring solution in place is a must. The typical monitoring solutions are e.g. Grafana which would be feature-rich but has no good native integration for launching browsers to emulate a real user. Also, you need to host it yourself which is mostly for monitoring solutions not advised (or you need a HA installation in another data center or cloud provider).

To fix these issues, Checkly has created a product to provide developer-friendly status checks, which can be used to launch browsers in the cloud. By using it you also don't need to spin up an own instance in your infrastructure since Checkly is a SaaS (Software as a Service) product and they host it for you. They even provide a full public dashboard for your customers. Starting from today they provide a full Playwright integration.

Usage

There are two types of checks which you can use. API checks to validate a given response body, status code, or schemas like JSON or GraphQL or browser-based tests on which we'll focus on this blog post. Browser-based tests are running a headless Chromium instance in the cloud to validate e.g. that your production login is working. Other common alternative scenarios would be:

Buy an item in your shop and validate that the user flow is working.
Validate that the OAuth login with e.g. Google is working.
Using a search on your website to ensure your elastic search in the background is correctly configured and serves the expected data.

Checkly itself gives you the ability to run any Node.js related code either with Playwright or Puppeteer to automate your user flows. They have a secret store built in to provide the secrets over to your code once it is running.

const assert = require("chai").assert;
const playwright = require("playwright");

const browser = await playwright.chromium.launch();
const page = await browser.newPage();
await page.goto("https://playwright.tech");

assert.equal(await page.title(), "Everything about the Playwright framework - Playwright Community 🎭");
await page.waitForSelector("text=Playwright Community");
await page.waitForSelector("text=Try Playwright");
assert.isAbove(await page.$$eval("article", elements => elements.length), 8)
await browser.close();

In this example we're ensuring the following checks:

Assert that the title has the expected value
Assert that "Playwright Community" is on the page
Assert that "Try Playwright" is on the page
Assert that at least 8 articles are on the page

If one of them is failing, Checkly will automatically treat this as a failing test and alert the user by e.g. Slack, PagerDuty, SMS, or Email.

Integrations

This at all replaces already quite a lot of common monitoring solutions. Instead of configuring complex user interfaces, you can create your own Node.js scripts that perform your status checks which will run in the cloud.

For more advanced integration, Checkly provides support for GitHub, which gives you a lot of other integrations like with Vercel or Heroku. This could e.g. be used to run your end-to-end tests on a Pull Request level with an environment that was created by one of these PaaS (Platform as a Service) providers.

Also for Terraform, one of the biggest solutions for infrastructure as code they offer integration on GitHub. This allows you to automatically manage large numbers of checks - a gamechanger when large APIs and hundreds of checks are involved.

Summary

Checkly provides an easy way of adding either status checks or entire end-to-end tests to your web applications which have now also Playwright support available. We at the Playwright Community are using it to ensure that the services which we publicly expose are on one hand high-available and on the other by that fully-functional when e.g. upgrading dependencies.

We're looking forward to how Checkly will make their monitoring solution even more accessible for developers with e.g. versioned code, an integrated Monaco editor with better auto-completion, support for custom NPM modules, or a better debugging experience. We would recommend giving it a try and have not to worry about where to run your status checks or end-to-end tests and benefit from their simplicity. For a more detailed outlook, they provide an official public roadmap on GitHub.

More information you'll find on checklyhq.com and on theheadless.dev a resource by Checkly to get started with Playwright.

Automate Chromium, Firefox, and WebKit with Go (preview)

Max Schmitt — Thu, 10 Sep 2020 18:55:11 +0000

Introduction

Automating browsers in the cloud, like on Kubernetes with a lightweight, type-safe, and easy to use programming language is especially useful for critical applications. In this blog post, we're gonna focus on the Go version of Playwright, what the current state is and what their limits are.

Playwright is a Node.js library to automate Chromium, Firefox and WebKit with a single API. Playwright is built to enable cross-browser web automation that is ever-green, capable, reliable and fast. Headless execution is supported for all the browsers on all platforms.

Playwright for Go aims to be a 1:1 wrapper of the JavaScript version. It uses like Playwright for Python the official driver implementation internally. Go has key differences compared to JavaScript and Python which affected on the Playwright implementation:

Dynamic values: When you interact with the browser process and want to execute JavaScript in it which returns dynamic values, Playwright for Go does internally convert it to the corresponding Go data types. In the user implementation, you have to cast it from the interface{} based type to the basic types, map[string]interface{} or []interface{}.
Optional parameters: For optional parameters, we are using structs with pointers to the basic types. We provide helper methods for String/Int/Bool/Float to make the developer experience smooth.

Examples

The core concept of the driver implementations like Go or Python is based on a sub process which is started in the background. This will be done with the Run() and the corresponding Stop() method.

Create screenshots

package main

import (
    "log"

    "github.com/mxschmitt/playwright-go"
)

func main() {
    // Launching the driver internally
    pw, err := playwright.Run()
    if err != nil {
        log.Fatalf("could not launch playwright: %v", err)
    }
    // Start the Chromium browser
    browser, err := pw.Chromium.Launch()
    if err != nil {
        log.Fatalf("could not launch Chromium: %v", err)
    }
    // Creates internally a context and a new page
    page, err := browser.NewPage()
    if err != nil {
        log.Fatalf("could not create page: %v", err)
    }
    // Visit the website and wait for a network idle for at least 500ms
    if _, err = page.Goto("http://whatsmyuseragent.org", playwright.PageGotoOptions{
        WaitUntil: playwright.String("networkidle"),
    }); err != nil {
        log.Fatalf("could not goto: %v", err)
    }
    if _, err = page.Screenshot(playwright.PageScreenshotOptions{
        Path: playwright.String("foo.png"),
    }); err != nil {
        log.Fatalf("could not create screenshot: %v", err)
    }
    if err = browser.Close(); err != nil {
        log.Fatalf("could not close browser: %v", err)
    }
    if err = pw.Stop(); err != nil { log.Fatalf("could not stop Playwright: %v", err) }
}

The core concept of Playwright is based on a browser that has multiple contexts. A single context is an isolated entity that has separate state for cookies or local storage. Each context has multiple pages with browser session shared between each other.

We specify networkidle to the Page.Goto() call which waits after there is a network idle on the page for at least 500ms. You can either pass then a path to the Page.Screenshot() method or use the returned data ([]byte) directly.

Automate websites

In this example we're navigating to Hacker News (popular tech news) site, crawling the current entries, and printing them to the standard output. This could in this case be done using HTML scrapers since Hacker News is based on returning rendered HTML but our approach would also work for dynamically generated sites with JavaScript which use e.g. React, Vue or Angular as a frontend framework.

package main

import (
    "fmt"
    "log"

    "github.com/mxschmitt/playwright-go"
)

func main() {
    pw, err := playwright.Run()
    if err != nil {
        log.Fatalf("could not start playwright: %v", err)
    }
    browser, err := pw.Chromium.Launch()
    if err != nil {
        log.Fatalf("could not launch browser: %v", err)
    }
    page, err := browser.NewPage()
    if err != nil {
        log.Fatalf("could not create page: %v", err)
    }
    if _, err = page.Goto("https://news.ycombinator.com"); err != nil {
        log.Fatalf("could not goto: %v", err)
    }
    // Looping over the DOM elements
    entries, err := page.QuerySelectorAll(".athing")
    if err != nil {
        log.Fatalf("could not get entries: %v", err)
    }
    for i, entry := range entries {
        // Finding the next title link element
        titleElement, err := entry.QuerySelector("td.title > a")
        if err != nil {
            log.Fatalf("could not get title element: %v", err)
        }
        title, err := titleElement.TextContent()
        if err != nil {
            log.Fatalf("could not get text content: %v", err)
        }
        // Printing it to the console
        fmt.Printf("%d: %s\n", i+1, title)
    }
    if err = browser.Close(); err != nil {
        log.Fatalf("could not close browser: %v", err)
    }
    if err = pw.Stop(); err != nil {
        log.Fatalf("could not stop Playwright: %v", err)
    }
}

In this example, we're making use of a selector on the latest news entries. We then loop over them, get its corresponding header/title element and print it to the console.

Summary

In this introduction, we went through two examples and an introduction of Playwright for Go and its current state. We are working to make it bulletproof, concurrent-safe, and adding more tests in the next few weeks to ensure it can be used in production. For further reference, see on GitHub.

playwright-community / playwright-go

Playwright for Go a browser automation library to control Chromium, Firefox and WebKit with a single API.

🎭 Playwright for

Looking for maintainers and see here. Thanks!

API reference | Example recipes

Playwright is a Go library to automate Chromium, Firefox and WebKit with a single API. Playwright is built to enable cross-browser web automation that is ever-green, capable, reliable and fast.

Linux	macOS	Windows
Chromium 105.0.5195.19	✅	✅	✅
WebKit 16.0	✅	✅	✅
Firefox 103.0	✅	✅	✅

Headless execution is supported for all the browsers on all platforms.

Installation

go get github.com/playwright-community/playwright-go

Install the browsers and OS dependencies:

go run github.com/playwright-community/playwright-go/cmd/playwright install --with-deps
# Or
go install github.com/playwright-community/playwright-go/cmd/playwright
playwright install --with-deps

Alternatively you can do it inside your program via which downloads the driver and browsers:

err := playwright.Install()

Capabilities

Playwright is built to automate the broad and growing set of web browser capabilities used by Single Page Apps and Progressive Web Apps.

Scenarios that span…

View on GitHub

Automate web browsers with Python and Playwright

Max Schmitt — Fri, 07 Aug 2020 09:48:43 +0000

Introduction

In this article, we're gonna focus on the current state of using Playwright with Python. Playwright is a Node.js library to automate browsers (Chromium, Firefox, WebKit) with a single API which provides now also the interfaces to provide other cross-language support, in this particular blog post Python.

In comparison to other automation libraries like Selenium, Playwright offers:

Being less flaky by auto-waiting for elements to be ready before executing actions (like click, fill)
Native support for emulating mobile devices, geolocation, and permissions
Better developer experience by automatically installing the browsers
Integrations for shadow-piercing selectors, native input events for mouse and keyboard or up-/downloading files

And by that, all these features are also available in the Python integration. Be aware, that Playwright Python is currently in beta but exposes already most of the common methods and functions to be used. Since communication with browsers is mostly async based, Playwright does also provide an async based interface. It's a developer decision in the end but in most cases, the sync version is easier debuggable with REPLs like ipdb, pdb, or IPython since they don't work with await and by that, your are more productive with writing your actual features.

Examples

Since the core concept of Playwright is also the same as in the Python version, the function calls are mostly the same except how you access the Playwright object. For that, you have to use the sync_playwright context manager with a with statement.

Page screenshot - sync

This code snippet navigates to whatsmyuseragent.org in Chromium, Firefox and WebKit, and saves 3 screenshots.

from playwright import sync_playwright

with sync_playwright() as p:
    for browser_type in [p.chromium, p.firefox, p.webkit]:
        browser = browser_type.launch()
        page = browser.newPage()
        page.goto('http://whatsmyuseragent.org/')
        page.screenshot(path=f'example-{browser_type.name}.png')
        browser.close()

Evaluate in browser context - sync

This code snippet navigates to example.com in Firefox and executes a script in the page context to determine the window dimensions.

from playwright import sync_playwright

with sync_playwright() as p:
    browser = p.firefox.launch()
    page = browser.newPage()
    page.goto('https://www.example.com/')
    dimensions = page.evaluate('''() => {
      return {
        width: document.documentElement.clientWidth,
        height: document.documentElement.clientHeight,
        deviceScaleFactor: window.devicePixelRatio
      }
    }''')
    print(dimensions)
    browser.close()

Intercept network requests - async

This code snippet sets up request routing for a Chromium page to log all network requests.

import asyncio
from playwright import async_playwright

async def main():
    async with async_playwright() as p:
        browser = await p.chromium.launch()
        page = await browser.newPage()

        def log_and_continue_request(route, request):
            print(request.url)
            asyncio.create_task(route.continue_())

        # Log and continue all network requests
        await page.route('**', lambda route, request: log_and_continue_request(route, request))

        await page.goto('http://todomvc.com')
        await browser.close()

asyncio.get_event_loop().run_until_complete(main())

Pytest integration

For writing actual end-to-end tests its common to use a test runner. In the Python world, Pytest is very common and we're using in our example the official Playwright integration for it. Instead of using it manually, it provides features like:

Have a separate new page and context for each test with Pytest fixtures
Run your end-to-end tests on multiple browsers by a CLI argument
Run them headful with the --headful argument to debug them easily
Using base-url to only use the relative URL in your Page.goto calls

It's Open Source and available on GitHub and installable with PIP:

pip install pytest pytest-playwright

Pytest has the concept that you have fixtures that will pass the values inside which are specified by the parameter name. In our case, we use for that page which will call the Playwright Pytest plugin to give us a page object.

def test_is_chromium(page):
    page.goto("https://www.google.com")
    page.type("input[name=q]", "Playwright GitHub")
    page.click("input[type=submit]")
    page.waitForSelector("text=microsoft/Playwright")

You can run it with pytest or optionally specify multiple browsers to run the test on like pytest --browser chromium --browser firefox --browser webkit which will run 3 tests in the end.

For more detail information about the Pytest usage, you'll find the documentation on GitHub.

Summary

Playwright Python is still beta, but for small projects with are not used in production its worth it to try it out to see if you benefit from it compared to other automation libraries. If you encounter any bugs or find some missing features, feel free to file an issue on GitHub.

microsoft / playwright-python

Python version of the Playwright testing and automation library.

🎭 Playwright for Python

Playwright is a Python library to automate Chromium, Firefox and WebKit browsers with a single API. Playwright delivers automation that is ever-green, capable, reliable and fast. See how Playwright is better.

Linux	macOS	Windows
Chromium 113.0.5672.53	✅	✅	✅
WebKit 16.4	✅	✅	✅
Firefox 112.0	✅	✅	✅

Documentation

https://playwright.dev/python/docs/intro

API Reference

https://playwright.dev/python/docs/api/class-playwright

Example

from playwright.sync_api import sync_playwright

with sync_playwright() as p:
    for browser_type in [p.chromium, p.firefox, p.webkit]:
        browser = browser_type.launch()
        page = browser.new_page()
        page.goto('http://whatsmyuseragent.org/')
        page.screenshot(path=f'example-{browser_type.name}.png')
        browser.close()

import asyncio
from playwright.async_api import async_playwright
async def main():
    async with async_playwright() as p:
        for browser_type in

…

View on GitHub

Using Playwright on Heroku

Max Schmitt — Thu, 09 Jul 2020 22:09:23 +0000

Introduction

Simplifying the deployment process nowadays of an application is a huge benefit to focus on the actual development instead of DevOps related tasks to create and configure a server for example. Heroku provides such a platform for running various tech stacks and languages easily and exposes them to the web which is called Platform as a Service (PaaS).

Using Playwright will give the developer the possibility to either use Playwright on Heroku CI, a Continuous Integration provider by Heroku, or using it on the Heroku platform on a normal Dyno. They can then perform tasks like end-to-end testing or making preview images of web pages by starting a headless browser instance and making a screenshot.

Overview

For the Heroku ecosystem, you need buildpacks, which can modify the system and hook into the compilation or test step of your application while it's building. For our case, we have to install the dependencies during the installation stage. Due to the requirement, that Heroku buildpacks are only allowed to modify the files inside the current working directory, the Playwright buildpack has to set an environment variable to store the browsers in the node_modules folder instead of a global directory.

Usage

There is already a buildpack available, which configures the system for Playwright. It will as required install the dependencies and adjust the Playwright configuration by setting an environment variable. You'll find it on GitHub.

If you want to use this buildpack, set the buildpack URL in your application either via the CLI or the web interface.

heroku buildpacks:set https://github.com/mxschmitt/heroku-playwright-buildpack -a my-app

It's important, that it's ordered before the Node.js buildpack, otherwise, the browsers won't be installed correctly.

Also, you can then adjust the environment variables of your application and set the PLAYWRIGHT_BUILDPACK_BROWSERS environment variable to the browsers which you want to install. For example, chromium to install Chromium only and save by that slug size. If you want to install more, separate them by a comma. WebKit is currently not yet supported, see on GitHub for more information about that.

It's also common to only install the browser-specific NPM packages, which will reduce installation time and slug size on Heroku in the end.

On the actual Playwright usage, it differs not much except that you have to run Chromium with the --no-sandbox argument because on Heroku the Chromium Sandbox is not supported. For the full usage of Playwright, see on their official website playwright.dev.

// Use the browser specific NPM package
const { chromium } = require("playwright-chromium");

(async () => {
  // Start Chromium with the '--no-sandbox' argument
  const browser = await chromium.launch({ args: ["--no-sandbox"] });
  const context = await browser.newContext();
  const page = await context.newPage();
  await page.goto('http://whatsmyuseragent.org/');
  await page.screenshot({ path: `chromium.png` });
  await browser.close();
})();

Summary

In this tutorial, we went through how to set up your Heroku environment to install the needed Playwright dependencies. Now you can start using your own logic by controlling the browsers. A full example of how it will look like in the end, you'll find on GitHub or on heroku.playwright.tech.

playwright-community / heroku-playwright-buildpack

Buildpack for running Playwright with Chromium and Firefox on Heroku.

Heroku Playwright Buildpack

This buildpack installs all the needed dependencies to use Playwright with Chromium and Firefox on Heroku.

Usage

For using this buildpack, you have to add the buildpack before installing your Node.js dependencies.

heroku buildpacks:set https://github.com/mxschmitt/heroku-playwright-buildpack.git -a my-app

For a full example, see here a usage with the Express library.

It's common to use the PLAYWRIGHT_BUILDPACK_BROWSERS environment variable which accepts a comma-separated list of the browser names (chromium, firefox, webkit). By default, it's installing the dependencies for all the browsers. To only install Chromium dependencies for example, just set it to chromium. This will reduce the slug size in the end too.

You should also install the browser specific NPM packages like playwright-chromium. to reduce the slug size.

Examples

Chromium

For using Chromium, it's necessary to use chromiumSandbox: false in the launch options, since on Heroku is no support for the Chromium sandbox.

…

View on GitHub

Using Jest with Playwright

Max Schmitt — Mon, 06 Jul 2020 22:32:47 +0000

Introduction

Having a test runner like Jest configured has a lot of benefits instead of writing your tests from scratch. It gives you out of the box the ability to focus a single test, providing a formatted output or a whole suite for common assertions called expect in Jest. The framework is maintained by Facebook and is mostly the default choice for writing frontend or backend unit tests in the JavaScript ecosystem. It's framework agnostic and by that, you can test with it e.g. your express backend or your React components.

The way how you should integrate Playwright into your project depends on your needs. Currently there two common ways of doing that. Either you can do it manually by using the hooks (beforeAll, afterAll, beforeEach, afterEach) or you use jest-playwright. We recommend to use jest-playwright due it has features like:

Multi-browser and device (like iPhones with given screen sizes) support
jest-dev-server integration which can start your webserver like create-react-app before running the tests
expect-playwright integration which provides common expect helper functions

Using `jest-playwright`

To get started we first have to install the needed Node.js packages either over NPM or Yarn. It's common to install them as devDependencies so they won't be installed on your production environments.

npm install -D jest jest-playwright-preset playwright

Instead of installing all the browsers with the playwright package, you can also just install e.g. playwright-chromium to save bandwidth and storage on your system and have a faster installation time.

Once we installed the dependencies, we have to create a Jest configuration to instruct Jest which preset should be used for which files. You can either reuse your existing configuration (jest.config.js) or create a custom one and name it e.g. jest.e2e.config.js. In the end, when you run your tests, you then have to specify the custom config file with the -c flag. It's also common to separate your unit tests from the end-to-end tests with a separate configuration file.

Inside the Jest configuration file you have to put:

module.exports = {
    preset: "jest-playwright-preset"
}

Also since this is a normal Jest configuration you can pass a RegExp or glob pattern which determines the files which Jest should run. It's useful to use e.g. a custom folder or file suffix as a naming convention to separate your unit tests from the end-to-end tests. See here as a reference for the testRegex and testMatch setting.

For the basic configuration this is already enough to get started. If you want to setup custom browsers, devices, screen resolutions or other launch settings for Playwright, then you need a custom Playwright configuration. Create a file called jest-playwright.config.js in the root directory of your project to use the settings which are described in the jest-playwright documentation.

module.exports = {
  launchOptions: {
    headless: true
  },
  contextOptions: {
    ignoreHTTPSErrors: true,
    viewport: {
      width: 1920,
      height: 1080
    }
  },
  browsers: ["chromium", "firefox"],
  devices: []
}

Keep in mind, that all the values in the configuration are optional and only showed here to give insights how it can be used in common testing setups.

To run your tests you can add jest or jest -c config.e2e.config.js to your scripts section of your package.json to run them easier by using npm run test.

Here's an example output how it will look like:

PASS browser: chromium src/e2e/platform.e2e.ts (23.729s)
Profile Settings
    ✓ should be redirected to login page if not logged in (568ms)
    ✓ should be able to login by email and password (404ms)
    ✓ should be able to see their email and name on account settings page (155ms)
    ✓ should be able to change their email and name on account settings page (562ms)
File handling
    ✓ should be able to import a CSV (705ms)
    ✓ should be able to view a files (742ms)
    ✓ should be able to delete a file (606ms)
    ✓ should be able to edit a file (806ms)

For more information about jest-playwright, you'll find the full documentation on GitHub.

Using it from scratch

As you can see in the following code, we use the lifecycle hooks to launch a browser before all the tests which run and close them once all are done. For every test beforeEach will create a new page as a global variable which will be used inside the tests. In this example we are visiting example.com and testing if the title of it contains Example Domain.

const { chromium } = require('playwright');
let browser;
let page;
beforeAll(async () => {
  browser = await chromium.launch();
});
afterAll(async () => {
  await browser.close();
});
beforeEach(async () => {
  page = await browser.newPage();
});
afterEach(async () => {
  await page.close();
});
it('should work', async () => {
  await page.goto('https://www.example.com');
  expect(await page.title()).toBe('Example Domain');
});

In the creation of the browser (chromium.launch) or the creation of the page (browser.newPage) you can passs options e.g. to start the browser as headful instead of headless to manually click around or to ignore invalid SSL certificates which is useful for local testing.

Writing tests

Once you have a setup in place, you can then follow up by using tools like expect-playwright (pre-installed with jest-playwright) which gives you a few utility methods on your Jest matching class to use it like that:

it("should...", async() => {
  // before
  await page.waitForSelector("#foo")
  const textContent = await page.$eval("#foo", el => el.textContent)
  expect(textContent).stringContaining("my text")

  // after by using expect-playwright
  await expect(page).toHaveText("#foo", "my text")
})

Or you are also able to assert the value of input DOM nodes on the page:

it("should...", async() => {
  await expect(page).toEqualValue("#my-element", "Playwright")
})

For more information about that we recommend to dig into these projects/articles to find out more:

Different selector engines on playwright.dev
Utility helper functions for Jest: expect-playwright
Run if needed your backend or frontend before your Jest tests with jest-dev-server

playwright-community / jest-playwright

Running tests using Jest & Playwright

Jest Playwright

⚠️ We recommend the official Playwright test-runner (@playwright/test) ⚠️

It's more flexible, lightweight, optimized for Playwright, and has TypeScript support out of the box. This doesn't mean, that we stop with maintaining this package.

Running your tests using Jest & Playwright

npm install -D jest jest-playwright-preset playwright

Also you can use jest-playwright-preset with specific playwright packages playwright-webkit, playwright-chromium and playwright-firefox

npm install -D jest jest-playwright-preset playwright-firefox

Requirements

Node.js 14+
Playwright 1.2.0+
Jest 28+

Usage

Update your Jest configuration, either:

with package.json:

"jest": {
  "preset": "jest-playwright-preset"
}

or with jest.config.js:

module.exports = {
  preset: 'jest-playwright-preset',
}

And add the Jest command as in the script section of your package.json:

{
  "scripts": {
    "test": "jest"
  }
}

Now you can use Playwright in your tests:

// example.test.js
beforeAll(async () => {

…

View on GitHub

Automate Microsoft Edge and Google Chrome with Playwright

Max Schmitt — Mon, 06 Jul 2020 22:29:53 +0000

Introduction

Testing a web application with end-to-end tests on the actually supported browsers is a real benefit to ensure that the application works as expected for example directly in the Continuous Integration workflow before it is merged and deployed. Playwright provides already full support for Chromium, Firefox, and WebKit out of the box without installing the browsers manually, but since most of the users out there use Google Chrome or Microsoft Edge instead of the Open Source Chromium variant, it's in some scenarios safer to use them to emulate a more real-life browser environment.

General

Since these browsers are based on the Chromium browser, Playwright interacts with them over the Chrome DevTools Protocol to open new tabs, click on elements or execute JavaScript. Due to this core requirement, we have to use a recent version (daily build - Canary) of them to ensure that the needed APIs schemas are matching and existing. To use them we have to only adjust the executable path option which Playwright will use to launch the browsers.

On macOS systems, the browsers are installed in the /Applications directory, where you have inside the related binaries. For Linux, the browsers are commonly installed in the /usr/bin directory, you'll find some examples below. On Windows systems, the browsers are installed in the C:\Program Files (x86)\ directory.

/Applications/Microsoft\ Edge\ Canary.app/Contents/MacOS/Microsoft\ Edge\ Canary - Microsoft Edge Canary on macOS
/Applications/Google Chrome Canary.app/Contents/MacOS/Google Chrome Canary - Google Chrome Canary on macOS
/usr/bin/google-chrome-unstable - Google Chrome Canary on Ubuntu
C:\Users\<username>\AppData\Local\Google\Chrome SxS\Application\chrome.exe - Google Chrome Canary on Windows
/Applications/Brave Browser Nightly.app/Contents/MacOS/Brave Browser Nightly - Brave Nightly on macOS

Note: To easier find out the executable path of the browsers, you can open the version page of the related browser. This would be edge://version, chrome://version or brave://version depending your browser. On this special site, you'll find the correct executable path if you have a GUI installed.

Browsers

const playwright = require("playwright-core");

(async () => {
  const browser = await playwright.chromium.launch({
    headless: false,
    executablePath: `/Applications/Microsoft\ Edge\ Canary.app/Contents/MacOS/Microsoft\ Edge\ Canary`
  })
  const page = await browser.newPage()
  await page.setContent(`<input id="foo">`)
  await page.type("#foo", "keksstar")
  console.log(await page.content())
  await page.screenshot({ path: "screenshot.png" })
  console.log(await page.evaluate(() => window.navigator.userAgent))
  // -> 'Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/85.0.4183.0 Safari/537.36 Edg/85.0.563.0'
  await browser.close()
})()

In the next couple of examples, we're gonna focus on the different browsers, which operating systems they support, where you can download them, and what executable path you need to set. This example demonstrates the basic usage by specifying the executablePath which launches Microsoft Edge instead of the normal Chromium. Also, we're using the playwright-core package, which only installs the library instead of downloading the browsers which we don't need in our case.

Google Chrome

Google Chrome is available for all the major operating systems and can be downloaded on the official website. To use Playwright, we need a recent Canary build. For Linux, it is common to install it via their APT repository, see e.g. this guide also keep in mind then to install the Canary variant: apt install google-chrome-unstable

Microsoft Edge

Microsoft Edge is only available for macOS and Windows and can be downloaded on the official website. Until now (Mid 2020) no Linux build was released. (It was announced in 2019 and confirmed the existence in Mid 2020 on their yearly Microsoft Build 2020 conference.) To use Playwright, we need a recent Canary build.

Brave

Brave itself does not rely on the official Chromium release schedule, that's why their latest versions are not the same as Chromium. Because of that it's not guaranteed, that all Playwright functionality is working out of the box. If you want to still try it out, you can obtain their Nightly version on their official website.

Other Chromium browsers

Other popular Chromium-based browsers like Vivaldi and Opera are not yet working which is tracked in this GitHub issue. For Firefox and WebKit, you have to use the attached

Summary

In this blog article, we went through an overview of how to use other Chromium-based browsers and control them with the Playwright library. We strongly advise, that these browsers will only be used when you need to test a very specific browser feature. For follow up usage and documentation about Playwright features, you'll find more on their official website playwright.dev.

Tracking frontend coverage of your e2e tests with Playwright

Max Schmitt — Mon, 06 Jul 2020 22:26:59 +0000

Introduction

End-to-End tests play a critical role in modern software development nowadays. As Guillermo Rauch (CEO of Vercel, formerly ZEIT) outlined in his last blog article about software development, software engineering teams attend to prioritize and implement End-to-End tests over normal unit tests. As an example, they start the real application setup and their dependencies to use it as a real user by browser emulation instead of testing e.g. React components and comparing input and output of them. Especially integrated into the Continuous Integration lifecycle with a CI provider like GitHub Actions ensures always, that the End-to-End tests are passing before they are merged and deployed to production.

With this mindset, its especially good for the team to have a way to track the actual coverage down to the code level, to see which functions and pages were executed with the End-to-End tests in our case with Playwright. Doing this manually is very time inefficient and error-prone. So we are focusing in this article, what tools and components you need, to automatically track the coverage and send it to your preferred coverage visualization provider like Codecov or Coveralls to have it visualized it like here on Coveralls.

Overview

There are multiple ways, to get the coverage data of your tests, you can use the Chrome specific coverage tracking feature, which gets the coverage data directly from the V8 runtime, but this is browser-specific and has no support for 1:many source-maps if e.g. your bundle is minified it wouldn't yet work, see here for more information.

In this tutorial, we are focusing on the usage with the Babel plugin babel-plugin-istanbul which you have to add during the build process (transcompilation) to your project. This will hold then the coverage data in a global variable called __coverage__ on the window object. Jest-Playwright, will automatically take care of storing and merging the coverage data. If you want to do it manually, you have to store it after each reload and page navigation because it's stored on the Window object which is not persistent.

Setting up Babel

The configuration with Babel depends on each application. In general its framework agnostic, so it can be used with e.g. React, Vue or Angular. In our example, we are using a React application with create-react-app which per default does not accept any additional Babel plugins, that's why we have to use a third-party tool called react-app-rewired to make it configurable. So in this case we have to create a file called config-overrides.js, to add the babel-plugin-istanbul plugin there. See here for the full file on GitHub and here for getting started with react-app-rewired.

const { override, addBabelPlugins } = require("customize-cra")

module.exports = override(
  process.env.E2E_TESTS && addBabelPlugins(
    "babel-plugin-istanbul",
  )
)

It's common to only add the babel plugin when you actually need the coverage information, for that we have there the test on the E2E_TESTS environment variable in place which we only set, when we bundle the web application for the end-to-end tests.x

Setting up jest-playwright

jest-playwright acts as a Jest environment which provides a Playwright Page instance for each test. After installing it with:

npm install -D jest jest-playwright-preset playwright

You can enable it in your Jest configuration jest.config.js:

module.exports = {
    preset: "jest-playwright-preset"
}

For a full reference for jest-playwright check out the official docs. Its also recommended using a separate Jest configuration for the e2e tests.

Collecting coverage with jest-playwright

jest-playwright will provide a method for saving the test coverage after each test and merging it after all the tests are completed. First you have to enable the coverage collection in the configuration in the jest-playwright.config.js file as follows:

// https://github.com/playwright-community/jest-playwright/#configuration
module.exports = {
    browsers: ["chromium", "firefox", "webkit"],
    serverOptions: {
        command: "npm start",
        port: 3000,
        launchTimeout: 10000,
        debug: true,
        options: {
          env: {
            E2E_TESTS: "true"
          }
        }
    },
    collectCoverage: true
}

In this example, we are also using the jest-process-manager to automatically start the React application before we are running the Jest test suite.

Once this is setup, jest-playwright, will start the development server and save the coverage data for all the pages which you are using inside the tests.

beforeEach(async () => {
  await page.goto("http://localhost:3000")
})

test("use Turquoise as a default background color", async () => {
  await expect(page).toHaveSelector("text=#1abc9c")
});

test("use Red as a background color", async () => {
  await page.click("text=Red")
  await expect(page).toHaveSelector("text=#e74c3c")
});

At that point, you can run your tests as usual with the jest command which is ideally configured in the script section of your package.json. When everything was successfully configured, you will see that the coverage data was successfully written to the file.

The output will be placed under the .nyc_output/coverage.json path, so it can be consumed using the Istanbul command line interface.

Visualize it using NYC

Once this is done, you can directly work with your coverage data by using the npx nyc report --reporter=html command which will create an HTML website in the coverage directory. You can then open the coverage/index.html file with your favorite browser to analyse it which will look in our example like as follows.

Uploading it to Coveralls/Codecov

It depends now on the coverage provider. Coveralls for example needs the lcov data format which is different from the format which we have generated (coverage.json). By using the nyc report --reporter=lcovonly command you can convert it to the lcov data format which will save the file under coverage/lcov.info. It's also useful to add it with the && syntax in the script section of your package.json to always generate the lcov data after running the test command.

Codecov on the other hand will accept the coverage.json file, so there is no need to convert it.

It also depends on the CI provider of your choice to upload it to the coverage provider. For GitHub, it's recommended to use the available official GitHub Actions:

Summary

In this tutorial, we went through the setup which is required to configure Playwright and Jest for storing and merging the coverage data of your End-to-End tests. You'll find the full repository on GitHub as a reference on GitHub.

Generate Open Graph images on-demand with Next.js on Vercel

Max Schmitt — Mon, 06 Jul 2020 22:24:00 +0000

Introduction

Images in social media like Twitter or Facebook are very important to give the user directly an overview of your content, topics, and a preview of it. Designing this manually takes usually time and knowledge in photo editing software like Adobe Photoshop or Gimp. In this tutorial, we'll cover, how to generate automatically preview thumbnails using Playwright and the Next.js framework. In general, this technique is framework agnostic and can be used with other alternative frameworks which support serverless functions.

Integration

The concept needs to be integrated into two parts of your application. The main layout or component that renders your pages needs to reference to your AWS Lambda function path. Due to the requirement of Twitter, that they need a full URL, we have to prefix the path with it. In Vercel, you have to manually add the VERCEL_URL environment variable to your project for building the full URL.

// Vercel specific
const getAbsoluteURL = (path) => {
  const baseURL = process.env.VERCEL_URL ? `https://${process.env.VERCEL_URL}` : "http://localhost:3000"
  return baseURL + path
}

Then we determine the path of the current page by using the useRouter React hook, this will be passed over to the servless function via a GET parameter. Also this component has the option to pass an existing image as a prop over which will be preferred to only use the generated screenshot as a fallback.

const MyComponent = ({ image }) => {
    const router = useRouter()
    if (!image) {
        const searchParams = new URLSearchParams()
        searchParams.set("path", router.pathname)
        image = `/api/thumbnail?${searchParams}`
    }
    // Open Graph & Twitter images need a full URL including domain
    const fullImageURL = getAbsoluteURL(image)
    return (
        <Head>
            <meta property="og:image" content={fullImageURL} />
            <meta name="twitter:image" content={fullImageURL} />
        </Head>
    )
}

The last step is to use something like react-helmet or next/head for Next.js to write the full image URL to the DOM.

Serverless function

Since the page is now referencing from the content over to the AWS Lamda function, we have to implement the automated screenshot generation. Currently, the only way for using Playwright on AWS Lamda is to use the playwright-aws-lambda package which uses a custom-built Chromium version under the hood.

Serverless functions are a standardized way of exporting an HTTP handler in a file which then will be available by the given file path. They are available in plenty of languages including Node.js, Go, and Python.

import * as playwright from 'playwright-aws-lambda';
import { getAbsoluteURL } from 'utils/utils';

export default async (req, res) => {
  // Start the browser with the AWS Lambda wrapper (playwright-aws-lambda)
  const browser = await playwright.launchChromium();
  // Create a page with the Open Graph image size best practise
  const page = await browser.newPage({
    viewport: {
      width: 1200,
      height: 630
    }
  });
  // Generate the full URL out of the given path (GET parameter)
  const url = getAbsoluteURL(req.query["path"] || "")
  await page.goto(url, {
    timeout: 15 * 1000
  })
  const data = await page.screenshot({
    type: "png"
  })
  await browser.close()
  // Set the s-maxage property which caches the images then on the Vercel edge
  res.setHeader("Cache-Control", "s-maxage=31536000, stale-while-revalidate")
  res.setHeader('Content-Type', 'image/png')
  // write the image to the response with the specified Content-Type
  res.end(data)
}

The Serverless function will in a nutshell launch the special Chromium instance, navigate to the given URL, create a screenshot, and then writes it to the response.

The entire source code for the page header and the Serverless function is available on GitHub.

Outcome

To summarize it, we created now the logic to generate dynamic Open Graph thumbnail images which will be generated on-demand if no custom image was given. They are automatically updated and cached on the edge of Vercel's webservers and look like the example above in our case.

Currently, it's only possible to use Chromium with a third-party library on AWS Lambda out of the box. For more information about the further progress, see here in the GitHub issue.

Record your Playwright browser with playwright-video

Max Schmitt — Mon, 06 Jul 2020 22:15:36 +0000

Introduction

Video recordings of your end-to-end test case execution can play a critical role. Not only would these help in debugging issues more efficiently, but you can use recorded videos to show test execution activities to your team and internal stakeholders. Additionally, these recorded videos can be added to your CI pipeline artifacts if a test is failing.

Currently, there is no native way of recording a session with Playwright's standards. But the QAWolf team has created for that a third party library to record Chromium based sessions. It's based on screencast feature which Chromium will expose over the Chrome DevTools Protocol.

Installation

To install it, you need the actual package and an available installation of ffmpeg. For most cases @ffmpeg-installer/ffmpeg should be enough which will download a precompiled binary of ffmpeg when you install your NPM dependencies:

npm i -D playwright-video @ffmpeg-installer/ffmpeg

Basic usage

It's implemented per Page level, that means you can have a recording for a single page which you start and stop as soon as you are done.

const { chromium } = require('playwright-chromium');
const { saveVideo } = require('playwright-video');

(async () => {
  const browser = await chromium.launch();
  const context = await browser.newContext();
  const page = await context.newPage();

  const capture = await saveVideo(page, 'recording.mp4');

  await page.goto("https://google.com")
  await page.goto("https://apple.com")
  await page.goto("https://github.com")

  await capture.stop()
  await browser.close();
})();

Once you have called the saveVideo function by providing the page, the browser session will be recorded and stored on the given filepath until you call the stop function. In the example above Playwright visits a few websites and then closes the session.

Usage with `jest-playwright`

To integrate jest-playwright with playwright-video you can use the available utility methods to hook into the startup and teardown of the Playwright session.

import { saveVideo } from 'playwright-video'

let capture
beforeAll(async () => {
  capture = await saveVideo(page, 'recording.mp4')
})

afterAll(async () => {
  await capture.stop()
})

describe('Profile Settings', () => {
  it('can visit a few web pages successfully', async () => {
    await page.goto("https://google.com")
    await page.goto("https://apple.com")
    await page.goto("https://github.com")
  })
})

The shown code does the same as the other implementation and navigates by that through three different websites. The recording will also be stored in the recording.mp4 file.

A complete working implementation of playwright-video with jest-playwright as a reference you also find in the official examples repository of jest-playwright project.

Integration in GitHub Actions

The big benefit of having recordings in place as mentioned is for example to debug failed or flaky tests easier. In most cases, you run the end-to-end tests in CI environments like GitHub Actions. Since we've already seen the integration with jest-playwright, we only have to adjust our CI pipeline configuration to upload the recording if the end-to-end tests are failing. For GitHub Actions a minimal example would look like that:

name: CI
on: push
jobs:
  e2e:
    runs-on: ubuntu-latest
    steps:
    - uses:
    - name: Use Node.js
      uses: actions/setup-node@v1
      with:
        node-version: 13.x
    - name: Install Node.js dependencies
      working-directory: frontend
      run: npm ci
    - name: Run e2e tests
      run: npm run test:e2e
    - uses: actions/upload-artifact@v2
      if: ${{ failure() || success() }}
      with:
        name: Chromium Recording
        path: recording.mp4

In this example after the general steps (checkout, install Node.js) are running the end-to-end tests as usual via jest-playwright (we call Jest in the package.json script section) will be triggered via npm run test:e2e. By adding the if condition to the action for uploading the artifacts, we instruct the CI provider to upload the recording also if the pipeline has failed. You then can download the file once you open the GitHub Action run on GitHub itself. For more information check out the official action to upload files actions/checkout on GitHub.

Playwright itself has on his roadmap for the next features in the upcoming few releases, that a native screencast implementation will follow. This will give us cross-browser support and probably a smoother video in the end.

DEV Community: Max Schmitt

Running Playwright Codegen with existing Chromium Profiles

Setting Up the Environment

Launching a Browser with the Default Profile

Using a Specific Browser Profile

Using Playwright Codegen

Running the Script

Important Notes

Useful links

Implementing Microsoft Entra Certificate-Based Authentication with Playwright

Introduction to Certificate-Based Authentication (CBA)

TLS Client Certificates and Their Role in CBA

Implementing CBA with Playwright

Troubleshooting

Useful links

Troubleshoot your Playwright or Puppeteer tests and find the root cause for failing tests

Introduction

Debugging tests

Integrations

Managing results

Root Cause Cloud

Summary

Monitoring with Playwright on Checkly made easy

Introduction

Usage

Integrations

Summary

Automate Chromium, Firefox, and WebKit with Go (preview)

Introduction

Examples

Create screenshots

Automate websites

Summary

playwright-community / playwright-go

Playwright for Go a browser automation library to control Chromium, Firefox and WebKit with a single API.

🎭 Playwright for

Looking for maintainers and see here. Thanks!

Installation

Capabilities

Automate web browsers with Python and Playwright

Introduction

Examples

Page screenshot - sync

Evaluate in browser context - sync

Intercept network requests - async

Pytest integration

Summary

microsoft / playwright-python

Python version of the Playwright testing and automation library.

🎭 Playwright for Python

Documentation

API Reference

Example

Using Playwright on Heroku

Introduction

Overview

Usage

Summary

playwright-community / heroku-playwright-buildpack

Buildpack for running Playwright with Chromium and Firefox on Heroku.

Heroku Playwright Buildpack

Usage

Examples

Chromium

Using Jest with Playwright

Introduction

Using jest-playwright

Using it from scratch

Writing tests

playwright-community / jest-playwright

Running tests using Jest & Playwright

Jest Playwright

⚠️ We recommend the official Playwright test-runner (@playwright/test) ⚠️

Requirements

Usage

Automate Microsoft Edge and Google Chrome with Playwright

Introduction

General

Browsers

Google Chrome

Using `jest-playwright`

Usage with `jest-playwright`