What tool to choose for Web UI Test Automation?

TLDR; I tried to objectively assess the web automation tool market. And as a new development team I’d probably choose Playwright, but as someone experienced in automating the web I’d still choose WebDriver.

Reviewing Automation Tools

I reviewed the market for Open Source and free Web Automation Tools so that I could more objectively answer questions like “What tool should we use for Web Test Automation”.

I tried to approach this like any development team would:

• web searches for tools
• read forums and comments
• read the documentation

But I also tried to project scalability. If the team starts to create a lot of Web UI coverage and wants to have many different versions of browsers available then which tools also let them use cloud providers as the execution agent.

This was a thought experiment so I didn’t prototype execution with each tool I have used both tools so for the purpose of this write up I skipped this step.

Web Searches

There are a lot of spam articles on “17 Best Web Automation Tools for 2025”. You could create random variations of this title and probably find an article using your generated title on the web.

What you find are random lists which lump paid no-code tools with unsupported niche code libraries mixed with commercial AI based tools. Also automation tools (Webdriver, Playwright) would be mixed with execution and design frameworks (Robot, Cucumber).

An impossible combination to search through and most of those pages offered me no value.

So the first thing a team has to decide are filtering criteria:

• paid or free and open source?
• code based or no-code based?
• AI or non-AI?

This will depend on the team. Development teams with coding skills are probably best served by looking for free code based tools. They will have the skill sets to take advantage of the flexibility provided.

Test teams with no coding skills will have a harder time choosing tools because there is so much competition for paid, no-code, AI tooling.

I’m focused on the free and code based tooling because I code, and I work with, Development teams with coding skills.

I also recommend that teams who are automating without these skills, try to develop these skills as it can help avoid tool lock-in and ultimately opens up more approaches for automating.

Community Sentiment Analysis

If I didn’t have much experience with the tools I’d check sentiment analysis and see what people were recommending on Community sites like Reddit.

• which_automation_tool_should_we_prefer_for_web
• any_recommendations_for_test_automation_tools
• as_a_newbie_to_automating_web_app_tests_which

Looking at the community comments Playwright is promoted more than Selenium WebDriver.

WebDriver seems to require a PR boost because it is seen as outdated. This is unfortunate because it isn’t.

At this point I’d have a smaller list of tools:

• Selenium WebDriver
• Playwright
• WebdriverIO
• Cypress
• Puppeteer

And as I start looking through them I realise that if I want the option to use multiple languages I really only have two options: Selenium WebDriver and Playwright. All the other tools require automating in TypeScript.

Multi-language support is only offered by Selenium WebDriver and Playwright, all other tools are aimed at JavaScript/Typescript. This is probably a natural side-effect that ‘web applications’ have a front end that is a mix of HTML, CSS and JavaScript so the obvious choice to automate the front end is using the language space of the web: which is TypeScript and JavaScript. But, many teams are polyglot with a mix of skill sets. The core development skill for a large application is going to center on the main code base, which is likely the back-end, and that might well be written in TypeScript, but could equally be Java or Python.

A library with support for multiple languages is likely to the be choice for most polyglot environments.

My two main choices for Web Automated Execution driven by coding would be Selenium WebDriver and Playwright.

The community comments might lead me to think that WebDriver is flaky and hard to use. But I’ve never found WebDriver hard to use, or to be the the root cause of flakiness in my execution. I’ve never needed self-healing locators or auto-waits for stability.

Some comments against WebDriver: “you need to have the right driver installed for the browser” were removed a long time ago, first by the Selenium Manager library and now this is built in to WebDriver so it is very easy to get started with WebDriver since it downloads drivers and browsers when required. Selenium Manager

If I read community comments about WebDriver driver and browser management I might be concerned, but I’d then see in the Playwright documentation that I have to manage the browsers for playwright using maven or npm commands see browers docs. The documentation for Playwright actually makes this seem harder than it needs to be because I’m pretty sure I’ve never done this with Playwright and it downloaded what it needed automatically.

Scalability Support - Online hosts for Web Automation Tools

Reviewing the online Web Automation SAAS tools can give a good indication of which libraries and tools are popular and scalable.

If you start using a tool heavily then you might want to expand the range of browsers that you automate against, this can be time consuming to setup locally so Online hosts might help by pointing the test code at a cloud instance for a specific browser.

• BrowserStack
  • https://www.browserstack.com/
  • Selenium, Playwright, Cypress, Puppeteer, WebDriverIO
• LambdaTest
  • https://www.lambdatest.com/
  • Selenium, Playwright, Cypress, Puppeteer, WebDriverIO
• SauceLabs
  • https://www.lambdatest.com/
  • Selenium, Playwright, Cypress, WebDriverIO
• TestingBot
  • https://testingbot.com/
  • Selenium, Cypress, Puppeteer, Playwright, WebDriverIO

Reading the documentation for these tools I’d learn of other tools which are mentioned when looking through docs of online hosts e.g. TestCafe, Nightwatch. But again these are not polyglot so wouldn’t really expand my options.

At this point I’d also see that with my short-list of tools I have options around scalability which don’t require me setting up my own multi browser environments.

Playwright vs Selenium WebDriver

I narrowed my choice down to Playwright vs Selenium due to multi-language support.

So now I have to go through the thought process of comparing the tools.

Perceived Execution Speed and Coverage

Playwright has the advantage that it is newer and only targets a subset of browsers and browser communication protocols, it has no support for legacy browsers, it has never had to concern itself with backwards compatibility.

If you need to use legacy browsers then you’ll probably use WebDriver.

Both WebDriver and Playwright are converging on the WebDriver BiDi W3C standard, so when this happens a choice between WebDriver and Playwright is likely to come down to the programmer oriented API.

Documentation

Comparing the Playwright and WebDriver documentation and we can see the advantage that a tool with Big Company support has.

Playwright is provided by Microsoft and has people paid to work on the documentation and examples. WebDriver is community driven and so naturally the Playwright documentation is currently more attractive than WebDriver.

For an experienced team this isn’t really an issue because the WebDriver API is very well documented at the code level and both projects have example code on Github.

For a team just starting out the documentation page and community comments could well swing people over to Playwright immediately but I would hope this wouldn’t be a deciding factor for experienced teams.

Auto Waits and Retries

Playwright is probably also viewed as ’easier’ because of the auto-waits. I have some experience with automating so this actually makes me nervous, I’ve seen auto-waiting and auto-synchronisation cover up application bugs.

The auto-wait conditions are documented on the Playwright site under actionability Here I can see the automatic synchronisation on check, click, etc. I checked the Playwright documentation and see that I can configure the auto-wait action timeouts so I can take control over that behaviour when necessary.

Playwright has auto-retrying assertions expect(locator).toBeEditable() which seem analogous to the WebDriverWait

API Coverage

The addition of API coverage from a single tool might push teams towards Playwright.

I personally prefer tools and libraries to be focused on ‘one thing’ and do it well

API coverage can easily be achieved on projects using WebDriver by adding specialised libraries for the coverage required e.g. HTTP libraries for API testing and mocking libraries for APIs.

The dynamic mocking that Playwright supports where network traffic from the current page are mocked is harder to achieve with WebDriver and requires Network access. But also, is that the ‘right’ place to test that functionality? I’d expect to see that covered pre-deployment at the code level rather than running integration level and would expect that to be covered by testing-library.com level component tests with a mock API.

Future Project Scope

For me, this API Coverage might act as a Risk that the scope of Playwright expands beyond what I would require.

The scope of Playwright might be trying to evolve to cover deployed application execution and component development testing (like Cypress or Testing Library).

I can also see that there are differences in functionality between the language variants with the Node.js version offering a web server for local execution. This also makes me concerned about future viability of some of the languages. Would Java always be a first class citizen in the Playwright world?

Since the feature set between Playwright and WebDriver isn’t too different, I probably wouldn’t worry too much about this because most of my library usage would be behind a set of abstraction layers and I’d be able to migrate the implementation of those layers to other tools if necessary.

What to choose?

If I was new to automating I’d probably choose Playwright.

I’d be nervous about the differences in language support, but it probably wouldn’t be enough to stop me. If I was automating in TypeScript it probably wouldn’t concern me because I suspect TypeScript is the primary supported language for Playwright. For .Net I probably wouldn’t be concerned because .Net is Microsoft and they’ll keep supporting it.

Both tools are very good, they are maintained, they are both fast, they are both converging on BiDi. Playwright has extra features, many of which can be added to WebDriver projects using other libraries.

But this is a hard choice. And is probably determined by the feature set that you think you need for automating.

A Minority View

I feel that I’m in a Minority at this point. For production web automating I’d still choose Selenium WebDriver with Java or Kotlin.

I have a strong preference for single-focus libraries that do not try to extend their functional remit too far so that helps sway me towards WebDriver so I personally would still choose WebDriver for production work, but I acknowledge that I am biased based on my previous exposure to WebDriver.

I’m pretty sure that when the WebDriver BiDi standard is moved out of draft and supported fully by all browsers that the differences between WebDriver and Playwright will be minimal, but WebDriver may have lost a lot of the installed user-base by that point as people have moved towards Playwright.

The weight of public opinion at the moment is pushing towards Playwright which I think is also a pity because the standards that make Playwright possible were created and pushed by the WebDriver project team.

There is obviously more money behind Playwright, but it’s free and Big Companies often choose not to support tools for business reasons. This risk feels unlikely to happen but it’s in the back of my mind.

I think WebDriver remains an essential part of the Web Automation eco-system and it is unfortunate that the Big Browser Companies like Microsoft, Google, Apple are not listed on the Selenium WebDriver sponsors page. Despite this the WebDriver team manage to continue to push for open standards that make automating the web easier and better, and maintain tooling across languages and browsers that other tools do not support.

Multiple Language Support Tools Summary

Selenium WebDriver

• https://www.selenium.dev/documentation/webdriver/
• Programming languages supported: Java, Python, CSharp (.Net), Ruby, JavaScript, Kotlin(Java)
• Browsers: Chrome, Edge, Firefox, IE, Safari
• Functionality is aimed at Browser Automation.

Playwright

• https://playwright.dev/java/
• Programming languages supported: Java, Python, JavaScript/Typescript (Node.js), .Net
• Documentation has some odd choices
• Functionality covers Browser, API Automation, API Mocking, Assertions, auto-waits, videos, screenshots, traces

TypeScript/JavaScript Language Tools Summary

There are a lot of tools in this category which I didn’t really look at e.g. Nightwatch, TestCafe, and a host of others. In some ways I made life easy by only considering a polyglot team. If you specialise in Typescript and JavaScript then you have a lot of options to evaluate.

WebdriverIO

• https://webdriver.io/
• a JavaScript based abstraction on top of WebDriver protocols and Appium and Puppeteer (https://pptr.dev/)
• Programming languages supported: Node.js (JavaScript/Typescript)

Cypress

• https://www.cypress.io/
• Chrome, Edge, Firefox, WebKit (experimental)
• Programming languages supported: Node.js (JavaScript/Typescript)

Puppeteer

• https://pptr.dev/
• Chrome Dev Team maintained JavaScript library that is an abstraction on top of the WebDriver Bidi protocol, works with Chrome, Chromium and Firefox
• Not recommended for normal Automated Coverage use cases, but if you want something lightweight that only targets a specific browser set, in JavaScript then have a look.
• Programming languages supported: Node.js (JavaScript/Typescript)

https://www.patreon.com/c/eviltester">Join our Patreon from as little as $1 a month for early access to videos, ad-free videos, free e-books and courses, and lots of exclusive content.