By: Alex Chaves – Senior QA Engineer and Advisor

I started using Selenium in 2009, it was my first experience with Web automation, coming from a background of desktop automation with license tools such as Test Complete. Back then it was refreshing, the integration with Java, all the possible things you can achieve, and on top of that using open source license which was great for small companies that cannot afford license tools.

I have used Selenium for different technologies and applications including streaming, banking, and health (usually lots of fields to fill out) industries. Selenium was the leader of the automation industry for at least a decade and the reason why it was there is because it was robust, versatile, and able to integrate with multiple solutions in the cloud for reporting and parallel execution.

Even though it was flexible it had some issues in my opinion, the main ones would be:

1. Initial cost
2. Drivers integration
3. Wait times

Initial cost and driver integration: Unfortunately selenium solution is not out of the box, when you need to build a new project from scratch it is required to implement all the logic required to manage the browser implementation if it is local or if it is working in a selenium grid or even if you are using a third party in the cloud such as BrowserStack or SauceLabs, in the end, this represent important time and money.

For the drivers you need to manage the latest version of the driver manually unless you use a third-party library such as WebDriverManager.

The wait times are probably the biggest weakness of Selenium if you talk with anyone who has been playing for a while with the tool they will tell you that they have experienced the case of “NoSuchElementException even when it is displayed on the screen”, then you try to resolve it with the explicit wait, then you check the implicit wait configuration and it is not working either. By far this is the main reason why automated tests with selenium are flaky and usually generate false positives. This is so annoying that it is more common than expected to find pieces of code using the “Thread.sleep()” command; even when it is not recommended and its behavior is completely unpredicted, but according to the engineer: “it was the only way to find that element”.

Now let’s compare Selenium, against the new pretty boy from the neighborhood: Playwright

What’s Playwright?

Some key factors

• Enables reliable end-to-end testing for modern web apps.
• Cross-browser. Playwright supports all modern rendering engines including Chromium, WebKit, and Firefox.
• Cross-platform. Test on Windows, Linux, and macOS, locally or on CI, headless or headed.
• Cross-language. Use the Playwright API in TypeScript, JavaScript, Python, .NET, Java.
• Test Mobile Web. Native mobile emulation of Google Chrome for Android and Mobile Safari. The same rendering engine works on your Desktop and in the Cloud.(Playwright, 2024)

So how is the performance of the Playwright compared to weaknesses from Selenium:

Driver integration and initial cost: as soon as you complete the installation of Playwright it is completely ready to start automation testing, you can write a test in just 10 lines and it will manage your driver logic automatically which saves a lot of time. I also handle screenshots and reports out of the box. This is a functional example of a test in Playwright using Python:

import re

from playwright.sync_api import Page, expect

def test_has_title(page: Page):

page.goto(“https://playwright.dev/”)

# Expect a title “to contain” a substring.

expect(page).to_have_title(re.compile(“Playwright”))

def test_get_started_link(page: Page):

page.goto(“https://playwright.dev/”)

# Click the get started link.

page.get_by_role(“link”, name=”Get started”).click()

# Expects page to have a heading with the name of Installation.

expect(page.get_by_role(“heading”, name=”Installation”)).to_be_visible()

In case you are wondering it is also possible to implement a Page Object Model (POM) using this tool with any of the supported languages. For more details  visit POM

The playwright has implemented auto-waiting: “Playwright performs a range of actionability checks on the elements before making actions to ensure these actions behave as expected. It auto-waits for all the relevant checks to pass and only then performs the requested action. If the required checks do not pass within the given timeout, the action fails with the TimeoutError.” (Playwright, 2024)

In other words, it means that you do not need to worry about explicit, implicit, or any type of timeout, everything is handled by the framework automatically. This will increase the percentage of reliability of your tests.

From my perspective after improving those weaknesses from Selenium, Playwright is a really powerful tool that allows you to focus on what matters: the implementation of reliable tests and the reduction of false positives due to timeout errors. It is supported by Microsoft and its popularity has been increasing in the last months it is worth considering it as the new potential tool in the market for functional automated testing.

My recommendation would be if you already have an automation framework using Selenium, try to implement a test in both platforms and compare the performance to have an idea of what is better for your case. If you are starting a new project from scratch and have not decided on a new automation tool try to run a proof of concept in Playwright and get familiar and see if it could be a good fit.

References

Playwright. (2024, February 12). Playwright.dev. Retrieved from https://playwright.dev: https://playwright.dev/python/docs/actionability

Alex Chaves