What is the Microsoft Playwright Automation Tool Guide

Automation Testing Published on:
Microsoft Playwright feature image

Before we go over Playwright, I want to address a question I’m frequently asked.

Why is browser-based test automation so tricky, regardless of which test tool I use?

The Challenges of Modern Browser Applications

Today’s web applications tend to be extremely rich and responsive.

Playwright Automating Modern Web Development

Additionally, developers are mainly building single-page applications that do a lot more in a browser tab than web applications used to do a decade ago.

The highly responsive behavior of web applications is primarily powered by handling asynchronous events.

For example, say you're picking a particular button on a page, and then stuff happens on the page.

These web applications are rarely isolated and usually involve your backend services talking over the network.

There are lots of asynchronous events that are happening inside an application, and being able to automate these things predictably is hard.

You may run into cases where a network takes slightly longer and prohibits the UI from being ready for a script to interact with it because it's still loading behind the scenes.

Or you might be expecting a new popup window to be released, and you may have to switch context and automate that window.

There are tons of scenarios like these involved in building web applications today.

This asynchronous nature creates difficulty for any sort of automation to work reliably, which is why so many developers and testers out there are struggling with automation.

This is where the whole idea of brittle or flakiness starts coming into focus.

Of course, most existing frameworks and drivers are doing what they can to improve things, but given the requirements of web applications today, it's a tough problem.

Because of this, the Playwright team saw a need for a tool that could keep up and handle this newer approach to web development.

So what is Playwright, and how can it help with today’s software development testing challenges?

Introducing the New Automation Testing Tool Playwright

Playwright is a new, open-source, JavaScript-based, cross-browser automation library for end-to-end testing.

The goal of Playwright is to provide a single API to developers and testers to automate their web applications across today’s three major browser engines:

Arjun Attam, the program manager on the Playwright team at Microsoft, told me they created Playwright explicitly for the web automation space. Their goal was to help introduce automation that is fast and reliable enough to execute the needs of the modern web.

You might be thinking, “Ummm…this sounds an awful lot like Puppeteer.”

And you would be right—partially.

But here's the thing.

Puppeteer avaScript Web Automation

How is Playwright Different from Puppeteer?

Playwright did start as a fork of Puppeteer.

For folks who aren’t aware, Puppeteer is a node library to automate the chromium browsers with the JavaScript API.

In a lot of ways, though, Playwright has a different philosophy behind it.

For one thing, it was designed for e2e testing, It is apparent when one looks at how the Playwright team created their API that it is was done with developers and testers in mind.

Arjun explained that they spoke to a bunch of developers and testers using various cross-browser automation tooling to automate their web applications in the context of end-to-end testing. What they discovered was that there were gaps in the ability to run these tests across multiple browsers.

They were also looking for a more straightforward API that simplified the learning curve for using automation.

So, his team created Playwright to focus on these e2e testing problems from the get-go.

But how?

How was Playwright Designed as a Web Testing Tool?

Playwright tries to approach the problem by introducing intelligence defaults that make things easy right out of the box. It also includes the capabilities required for more advanced scenarios.

When you create and run a Playwright script, it runs through a bunch of checklists and ensures that the UI is ready for the test to execute the actions.

As users, we're naturally hardwired to wait for these things, but many tools require you to code for these scenarios. Instead, Playwright tries to handle these types of issues for you automatically.

For example, actions in Playwright auto wait for elements to be ready before your test interacts with them.

Waiting for an element to be ready is a typical pattern that developers have to write into their code explicitly. But Playwright does this automatically for you behind the scenes.

This feature makes it easier for you to write tests and, in turn, can make your tests more reliable.

It was also designed to allow you to run on all the major browsers (Chromium, Firefox, WebKit, et al.)

Additionally, they added newer testing capabilities to support things like an API for file downloads, and support to better handle out-of-process iframes, site isolation, and browser contexts.

Other supported capabilities are:

  • Scenarios that span multiple pages, domains, and iframes
  • Auto-wait for elements to be ready before executing actions (like click, fill)
  • Intercept network activity for stubbing and mocking network requests
  • Emulate mobile devices, geolocation, permissions
  • Support for web components via shadow-piercing selectors
  • Native input events for mouse and keyboard
  • Upload and download files

This tool's goal is to provide a flexible API with enough capabilities so that you can avoid common issues that cause brittleness or flakiness without having to anticipate them ahead of time programmatically.

Another design choice was to center Playwright around the notion of browser contexts.

What are Browser Contexts?

Browser contexts are isolated environments built on a single browser instance. They make it possible to create concurrent tests that are entirely separate from each other, and executes in parallel to browser context.

Browser contexts also enable you to emulate scenarios where you're changing the device viewport, permissions, or GEO locations across multiple pages.

Once again, the goal is to have Playwright fit the needs of developers and testers for creating end-to-end tests.

Can you Run Tests in Parallel?

Browser context really comes into play when discussing parallelization.

When you're automating a web application, you're using a browser instance. You can launch these browser instances; you can close these browser instances.

Playwright introduces a concept called browser contexts, which is central to the execution model. So, one single browser instance can be used to create multiple, concurrent, isolated browser contexts.

These browser contexts are extremely fast and inexpensive to create, so you can create hundreds of browser contexts, and you can close them down as needed.

Each browser context can also host multiple webpages.

For example, if you're using the single WebKit instance and you're creating a browser context on top of that and running your scripts inside that browser context.

Now because these browser contexts are isolated and concurrent and you can actually run parallel tests with a single instance of WebKit across multiple contexts.

Multiple Browser Viewport

Every context can have a specific browser viewport.

It can have a specific permissions configuration. It can have default geolocation.

That means it can create a browser context for the iPhone viewport with geolocation set to zoom, for example, giving it a particular set of permissions and running your web application within that emulation environment.

You can probably imagine a scenario where you want to run your tests across a matrix of mobile, desktop, viewports, and geolocations with different permissions.

So you can spin a browser context for each one of those parameters and run them in parallel.

Typically, a single browser instance can be costly to launch and close but can be reused in isolated environments by browser contexts. You can use this technique to parallel execute your tests across multiple sets of emulation scenarios.

This feature is built into Playwright.

Great for Scenarios that Require Authentication Test Cases

Another cool thing you can do with this feature is emulate, in a browser, the context of authentication credentials.

For instance, many applications use browser cookies to define authentication state.

Using two different browser contexts on the same browser instance, where you have two different authentication credentials.

All applications have a sense of permissions and user roles.

So you could log in as an administrator in one context and log in as a dummy user in the other context and essentially run your test in parallel across these two different authentication credentials.

Again, the key thing here is to reuse the instance, which means that you're not spending time launching a new browser or closing it and recreating it again and again.

You can do this expensive operation of launching before your tests execute and essentially create new contexts that are extremely fast and cheap to create and destroy in the context of your tests.

Speaking of running tests in parallel, does it support continuous integration and continuous delivery?

Does it work with CI/CD

To make it easy, Arjun's team released many recipes that are available across multiple CI providers. So they have documentation on getting started with:

These tools are super popular, and they are part of the broader developer experience of using Playwright.

To make your test automation CI/CD efforts event easier, they also released a docker image. So if you're not using one of these CI providers, you can use a docker container instead to get started with cloud deployment of Playwright with that docker image.

Also, with the release of a GitHub action for Playwright, if you don't want to dive into the configuration and have something that just works out of the box, this is a great option.

Using GitHub actions and the Playwright GitHub actions added to your action's YAML can quickly get started with running Playwright on CI.

Is there a test recorder?

Although it currently doesn't come with one Testim recently created a free one for it called Playground.

One of the challenges of using Playwright and Puppeteer is that you need to write tests in code, which takes time and effort to get right.

Codeless test automation solutions can enable fast recording of user journeys that can then be configured in an editor or in code.

This free recording eliminates many of the mundane and repetitive tasks of writing tests.

This accelerates test creation to keep pace with shrinking release cycles and helps build the test coverage needed to ensure quality.

Oren Rubin founder of Testim explains:

Oren also mentions a few cons of using the headless browser tool Playwright in his TestGuild Meetup Session

  • No support for IE 11
  • currently no easy grid solution
  • no plugins system,
  • not many integrations,
  • API is still changing – they just reached version 1.0 recently

Final Thoughts

As you've seen, Playwright is built to be extremely modular and focused on being an automation driver that works nicely with other parts of your testing stack.

Check it out on Github, give it a try and let me know what you think.

2 responses to “What is the Microsoft Playwright Automation Tool Guide”

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Microsoft Playwright feature image