Playwright – An Introduction

Written by: Minh Kha Giai

I. First act: “To be or not to be, that is the question”

“Playwriting can involve crafting complex characters and themes or revealing one’s innermost thoughts on stage. Similarly, in software testing, we have test engineers who use tools like the Playwright framework to write and execute test scripts. Just as a playwright creates a script for actors to perform, a test engineer creates scripts for automated tests to verify the functionality of software products.”
In this article, I will share with you some information about Playwright, a solid Web automated testing framework developed by Microsoft.

What is Playwright?

Playwright is an open-source test automation framework for E2E web testing and a cross-browser, cross-platform automation framework. It was designed to be an ever-green, capable, reliable, and fast automation framework with a single unified API porting to multiple programming languages. Its API can be used to automate Chromium, Firefox, and WebKit browsers. Playwright can be run locally (or in your CI pipeline) in headless (or headed) mode on multiple OS platforms. Currently, Playwright actively supports programming with NodeJS, Python, .NET, and Java. Playwright is chosen as a test framework for many enterprises and open-source projects: VSCode, Bing, Outlook, Disney, Nasa, Adobe, React Navigation, etc.

II. Second act: Pros and Cons of Playwright

Pros

• Support multiple programming languages (NodeJS, Python, .NET, Java) with a single unified API. The core API is written in NodeJS.
• Multiple platforms: Windows, WSL, Linux, macOS, Electron (experimental), Mobile Web (Chrome for Android, Mobile Safari)
• Multiple browsers: Chromium family (Chrome, MS Edge, Opera), Firefox, WebKit
• Popularity: since its release in Jan 2020, Playwright has experienced a steady increase in usage and popularity

• Open Source: Playwright comes with Apache 2.0 License, so all the features are free for commercial use and free to modify.

• Documentation, and community support: Though Playwright is a newcomer in the market, they have a steadily growing community.
  • The Playwright Team has an active presence on all its channels (GitHub, Slack, Stack Overflow, Discord). The team is very responsive to questions and feedback from the community.
  • There are various kinds of resources on the Internet (documents, blogs, videos, slides, etc) available to help us to become a Playwright hero from zero. The official documentation is written quite well.
• Solution for Flakiness: To reduce flakiness, Playwright has proposed some solutions below:
  • Wait mechanism:
    • Use Auto-Wait feature: Playwright makes sure that when you are interacting with a DOM element, the element is loaded stably before the action is performed. Under the hood, before interacting with the element, Playwright performs a range of actionability checks on the elements and waits until all the checks are passed in a configured timeout.
    • Use Playwright Smart Wait API. In some web pages, the usage of the auto wait feature is not enough. For example, in some cases, we have to wait for an explicit event to occur or wait for the web page to reach a desired UI state. Playwright Library provides us a set of APIs for explicitly waiting for a specific condition (wait for elements, navigation, network requests/responses, events, JS functions)
  • Use Web-first assertions. Test assertions are automatically retried until the necessary conditions are met, and race conditions can be eliminated. This is an extension of the ‘expect’ library from Jest. They have a rich set of matcher functions applied for every type of assertion.
  • Configure a Test Retry strategy, capture execution trace, videos, and screenshots to locate the root cause of flakiness.
  • Architecture Design (Communication): Playwright uses ChromeDevTool (CDP) – WebSocket protocol to communicate with the Chrome browser’s rendering engine. WebSocket is a stateful protocol. Playwright will communicate all requests through a single web socket connection that remains active until all tests have been completed. This design might reduce points of failure during test execution.

• Support for automating Multiple Tab / Browser Windows scenarios: Playwright supports writing scenarios that handle multi-tab, multi-browser, and multi-context by using their BrowserContexts feature. For example, we can use this to verify the scenario where 2 different users A & B are chatting with each other in a chat room.
• Locator strategy:
  • Playwright supports various locator types: id, class, CSSSelector, XPath, Angular/Vue/React component, accessibility attributes, etc
  • Ability to filter locators, chain multiple locators together, locate elements by their relative layout, to define your own selector by customizing the default selector engine
• Networking: Playwright provides many APIs to monitor and modify network traffic, we can:
  • Intercept the network requests/responses to modify the requests/responses
  • Abort some kind of requests to simulate a scenario where third-party resources in a web page are blocked by a browser’s extension (like AdBlock)
  • Generate throttling to simulate network delays
  • Mock API Calls, browser’s API that is unsupported by Playwright
• Test Isolation:
  • Each test in Playwright is executed in a unique browser context. A browser context is equivalent to a browser’s incognito-like profiles. This means that each context has its own local storage, session storage, cookies, etc. This delivers full test isolation with zero overhead. They are fast and cheap to instantiate.
  • By using the BrowserContexts, you can save the authentication state of the browser contexts into a file and reuse it in another browser context, in another test case, or in all of the tests. This bypasses repetitive login operations in each test.
• Test Structure:
  • Page Object Model (POM) support
  • Fixture (Playwright Test): Playwright Test takes the idea of POM further by introducing the test fixture. Fixtures are used to establish the environment, the page object, and the shared object for each test in isolation. We can define our shared objects’ instantiation logic into one fixture to use them later in any test cases. Hence, we don’t have to put more boiler-plate setup, and teardown code in every test file.

• VSCode extension for Playwright Test
• Other features:
  • Parallelism & Sharding: Playwright runs your test suite in parallel by default in multiple workers. You could break your test suite into multiple shards to run on multiple machines
  • Built-in reporters, 3rd party reporters, or customize your own reporter
  • CI/CD Integration support, Selenium Grid support, Docker support, Electron support
  • iFrame support, Shadow DOM auto piercing
  • Visual Testing (compare screenshots pixel by pixel)
  • Component Test (experimental)

Cons

• Playwright is quite new. The first official release was 3 years ago.
• Only supports browsers with a modern rendering engine, does not support IE.
• Only supports Mobile Emulation, does not support Native Mobile apps.
• Playwright needs to download a specific version of the browser binaries to operate. Playwright Team must keep up with the release of the stock browser (Chromium, Firefox, WebKit) by patching, and re-compiling the browser binaries so they will have all the functionalities that Playwright needs. As per the team, they always have one release ahead of the official release of the browser, so the latest version of Playwright always supports the latest browser’s version. We could also build a library of older browser binaries in our local machine to test to ensure backward compatibility for each browser’s version.

Compare with other frameworks

III. Third act: Why should we choose Playwright for automated testing?

Below are some of the features that I think would make Playwright shines:

• Leverages the DevTools protocol to write powerful, stable automated tests.
• Regarding Playwright architecture, it can see into and control the browser rather than relying on a middle translation layer, which allows for the simulation of more relevant user scenarios.
• Provides many tools to enhance the dev experience.
• Solutions to resolve flakiness: auto-wait, web-first assertions, etc
• Solutions to structure your test cases, make your test cases isolated from each other.
• Ability to work with multiple browser contexts, tabs, windows, and origins.
• Support for multiple browsers, multiple platforms, and multiple programming languages with a single unified API
• Provide Networking, mocking features to perform many abnormal scenarios
• Support for multiple Testing Types: UI Test, API Test, Component Test, Accessibility Test

IV. Final act: Conclusion

I hope that you have a better understanding of Playwright after reading my article. Final question, do you want to be a playwright in Playwright?

References:
https://github.com/microsoft/playwright <- Official Source
https://playwright.dev/docs/intro <- Documentation
https://playwright.slack.com/ <- Slack Community
https://github.com/mxschmitt/awesome-playwright <- A curated list of tools, utils, projects using Playwright
https://npmtrends.com/cypress-vs-playwright-vs-puppeteer-vs-…

Minh Kha Giai is a Senior Automation Test Engineer at NashTech (www.nashtechglobal.com)