There are many other popular open-source testing tools out there, but I thought I would next tackle one of the newer, but fastest-growing test automation tools on the market in Playwright. With the tool landscape already quite competitive with many tools offering an incredible range of features, it takes something special to see a newly established tool make big inroads into the market in such a short space of time. So, what is it that makes people so excited about Playwright and what does it offer that is different from the rest of the market?
Well, for a start, what has helped Playwright rise so quickly in the open-source tool automation landscape is that, unlike several other open-source platforms which rose from obscurity and took a while to eventually get support from big commercial players, Playwright was the brainchild of Microsoft, who saw a need to build a testing tool that did something different and they were able to use their vast development experience to craft something that addressed real-world issues, while also providing it with the industry support to gain quick recognition.
The origins of Playwright come from Puppeteer, a tool that I will be getting into next, and it makes use of many of the same API methods to interact with browsers and operate. Like Cypress, it is also a node.JS-based tool and therefore can also interact with elements of the site itself, rather than just purely acting as a client against the browser. It also operates on a WebSocket protocol as opposed to a traditional HTTP protocol that traditional tools like Selenium have used in the past.
The biggest differentiating point of Playwright is its cross-browser compatibility. It can drive Chromium, WebKit (the browser engine for Safari), and Firefox. Along with this, starting a new library allowed Playwright to improve ergonomics in ways that would break Puppeteer. For example, Playwright’s page.click waits for an element to be visible by default.
It's features like these, that reduce timeout and syncing issues that make test execution in Playwright less brittle than the likes of Selenium and allows for consistent and reliable test results and your test failures are likely to be more legitimate than the result of any configuration error.
Playwright is also capable of simulating multiple browsers with a single instance, with each browser's context even containing multiple pages underneath it, and able to operate in a completely isolated manner, allowing for the best parallel capabilities among all the tools.
Playwright works on three core concepts: browser, context, and page.
Browser: To run the tests, you must initiate the browser. Using Playwright, you can use the object of the Browser class, an instance of Chromium, Firefox, or Webkit.
Context: The Playwright framework achieves parallelization using browser contexts. The browser contexts are like incognito-like profiles isolated within a browser instance.
Page: It is a new tab (or pop window) within a browser context. Every action on the test will be performed on the page.
It is arguably though more complicated to use as its built with function and performance in mind rather than simplicity and its lack of a lot of prebuilt commands, requires the test authors to do more programming than many other similar tools. If you have a technically capable team of testers though the performance benefits, especially when executing tests across different browsers in a pipeline, will be well worth it.
Below are some of the pros and cons of the tool:
Pros:
Reduced flakiness in test execution: In removing the connection termination at the end of every request, there is less chance of a syncing issue causing a test to fail due to connection failure, giving the tool more reliable test results.
Headless execution: Like Puppeteer – a tool I will get to next – Playwright can execute in a headless format which means the site doesn’t need to fully render itself in order to execute a web application's functionality. This allows it to run far more quickly than many other UI automation tools.
Multi-Browser Support: Playwright supports multiple browsers, including Chromium, Firefox, and WebKit. This allows users to test their web applications across different browsers without the need to modify their test scripts.
Native WebDriver Support: Playwright natively supports the WebDriver protocol, making it easier to migrate existing Selenium scripts to Playwright.
Detailed reporting and debugging: Playwright can produce HTML reports out of the box that tracks execution runs both locally and in CI. In addition, it takes screenshots, videos, and traces of all failures which makes for easier debugging.
Integration with popular test frameworks: Playwright can be integrated with popular testing frameworks, such as Jest and Mocha, making it easy for developers to write and run tests in their preferred testing framework.
Cross-Platform Support: Playwright supports multiple operating systems, including Windows, macOS, and Linux, making it easy to run tests on different environments.
Cons:
Learning Curve: Playwright's API is powerful, but it has a steeper learning curve than some other tools. As it does not come with commands that take care of many testing features it requires the test automation team to take care of many of these features themselves. This does make the tool more maintainable, but users may need to invest more time in learning the API and the best practices for writing tests in Playwright.
Limited Documentation: Playwright is a relatively new tool, and its documentation is still evolving. Users may find it challenging to find comprehensive resources and documentation on specific features or use cases.
Limited Community: Compared to other testing tools like Selenium, the Playwright community is relatively small. As a result, users may not have access to as much support or resources as they would with a more established tool. Don’t expect this to last long though as industry support is fast improving.
Limited Browser Support: Although Playwright supports multiple browsers, it currently does not support some of the less commonly used browsers.
Nested failure reporting: Screenshots, videos, and traces of failures are made inside one test() function. It means that if you have a few tests inside test.describe(), you will get videos and traces for each nested test, but not for a whole root test function (steps have the same behavior). Essentially this means that there is a duplication of many of the failures which take up unnecessary space.
When to select Playwright:
When you need high automated execution speed in your pipelines
If your existing test automation struggles with a lot of flakiness and you need to improve the authenticity of your test results
If you need to transition to a pipeline-based CI testing tool like Cypress or Puppeteer, but have a lot of existing Selenium scripts.
If you have a technical testing team that understands coding fundamentals.
Playwright may be a newcomer in the automation space, but with the backing of Microsoft and the foundation of Puppeteer, it has a lot to offer and with Microsoft rapidly improving the tool and its feature set, it has a lot to offer many companies in the space.
コメント