Before we get into the Microsoft Playwright JS Automation Tutorial, 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?
Here is my answer.
What Are The Challenges Of Modern Browser Applications?
Today’s web applications tend to be extremely rich and responsive.
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 app 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 a web 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 Microsoft Playwright JS 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?
What Is Microsoft Playwright JS?
The goal of Playwright Node.js 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 JS 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.
Playwright Vs Puppeteer?
Playwright by Microsoft did start as a fork of Puppeteer.
In a lot of ways, though, Playwright API 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.
Is Playwright Js A Web Testing Tool?
Playwright JS tries to approach the problem by introducing intelligence defaults that make things easy right out of the box. It's easy to install playwright and 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.
Hands-on Microsoft Playwright JS Tutorial Examples
For example, actions in Microsoft's Playwright auto wait for elements to be ready before your test interacts with them.
How To Wait For An Element Using Playwright
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.
What Are The Microsoft Playwright JS Supported Capabilities?
- You can create scenarios that span multiple pages, domains, and iframes
- Time-saving auto-wait for elements to be ready before executing actions (like click, fill)
- You can intercept network activity for stubbing and mocking network requests
- Playwright JS can even emulate mobile devices, geolocation, permissions
- This tool supports web components via shadow-piercing selectors
- Allows you to tap into native input events for mouse and keyboard
- Can be used to upload and download files
- Headless execution
- Cross browser web automation
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 Languages Does Playwright JS Support?
What Are Microsoft Playwright 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.
How To Run Playwright 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.
Playwright Tutorial On How To Browser Viewports
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.
Supports Scenarios That Require Authentication Test Cases
Another cool thing you can do with this feature is to 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?
How To Use Microsoft Playwright JS With CI/CD Pipelines
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.
What Is The Playright JS 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 also mentions a few cons of using the headless browser tool Playwright Node.js 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
As you've seen, Microsoft 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.