I Was Wrong: Selenium vs Playwright in 2025

Source: Dev.to

As I reflect on 2025 and look ahead to 2026, I want to share a lesson learned.

Throughout last year, I didn’t have a single project where we built new automated tests with Selenium. Every conversation was about either using SaaS‑based tools or building with Playwright. All those Selenium projects that used to come in—now I’m just quietly maintaining and updating automated test systems that were originally built with Selenium.

If someone asked me today, “We’re starting web test automation and you have free rein—which testing tool or framework should we choose?” I would answer Playwright is the better choice.

A year ago I would have said, “It doesn’t matter. They all do the same thing.” Looking back now, I have to admit that was completely wrong. I was mistaken.

I think it’s the price I’m paying for being too busy to properly explore new tools. Recently, I’ve had more opportunities to work with Playwright (thanks to AI), so I’d like to share my observations.

Why the Shift?

Behind the shift to Playwright lies a transformation in the test‑automation landscape.

• In the past I received many requests for tests that would detect differences between browsers:
  “Please verify that it works the same on Chrome, Firefox, Edge, and Internet Explorer.”

• Now such requests are rare.

The biggest impact was the end of Internet Explorer (I know—that was ages ago!). IE had its own rendering engine, and compatibility issues with other browsers were endless. With IE gone, major browsers have consolidated into:

• Chromium‑based (Chrome, Edge)
• Firefox
• Safari

This dramatically reduced cross‑browser differences. Selenium’s great strength was its ability to control multiple browsers uniformly, but the situations where that strength matters have diminished.

With over 20 years in test automation, I’ve found that the challenges I felt with Selenium are being addressed by Playwright.

The Selenium World

Locators

// Typical locator strategy in Selenium
driver.findElement(By.id("submit-button"));
driver.findElement(By.cssSelector("#form > div.container > button.primary"));
driver.findElement(By.xpath("//div[@class='modal']//button[contains(text(), 'Submit')]"));

• We had to think about selector hierarchy – ID first, then name, CSS, and finally XPath.
• Every time the DOM structure changed, selectors needed updating.
• Tests breaking because a developer renamed a class was not uncommon.

Wait Handling

// Explicit wait in Selenium
WebDriverWait wait = new WebDriverWait(driver, Duration.ofSeconds(10));
WebElement element = wait.until(
    ExpectedConditions.elementToBeClickable(By.id("submit-button"))
);

// The common “just wait” anti‑pattern
Thread.sleep(3000);  // Fixed 3‑second wait

• Setting appropriate wait conditions was difficult, so we often fell back to fixed waits.
• Consequences:
  • Unnecessarily long execution time.
  • Flaky tests in some environments.
  • Overall execution time ballooned.

We were constantly struggling with the trade‑off between stability and speed.

The Playwright World

Role‑Based Selectors

// Role‑based selectors in Playwright
await page.getByRole('button', { name: 'Submit' }).click();
await page.getByLabel('Email Address').fill('test@example.com');
await page.getByPlaceholder('Enter search keyword').fill('Playwright');

• Elements are identified by the role and name that users perceive, not by DOM structure.
• As long as the button is named “Submit,” the test continues to work even if the HTML changes.
• This aligns with accessibility principles; screen readers use the same roles and ARIA labels.
• In the AI era, this is even more important: AI‑driven automation (e.g., Playwright MCP) is shifting from the DOM to the Accessibility Tree (ARIA Snapshot). Getting comfortable with role‑based selectors is an investment in the future.

Auto‑Waiting

// Wait handling is automatic in Playwright
await page.getByRole('button', { name: 'Submit' }).click(); // ← auto‑waits until clickable

• Playwright automatically waits for elements to be visible, enabled, and for animations to finish.
• Fixed waits are almost never needed.
• Benefits:
  • Reduced test execution time.
  • Fewer flaky tests.
  • Lower maintenance costs.

Quick Comparison

* Playwright Test is only available for TypeScript/JavaScript. The Java version requires separate frameworks like JUnit.

Final Thoughts

Regarding browser management, Selenium does have its advantages. Selenium launches the actual browsers installed on your PC, so you can test in the same environment as your users. Playwright, on the other hand, automatically downloads and uses dedicated browser binaries.

From Selenium to Playwright

“Easier to set up, but strictly speaking, not ‘the exact browser your users are using.’”

As you can see from the table, Selenium is “a mechanism to automate browsers,” and in terms of testing it requires separate test frameworks. This meant needing various peripheral knowledge—JUnit, TestNG, wait‑handling best practices, reporting tools, and more.

Playwright, on the other hand, is a test framework itself. It comes packed with testing‑specific features, and being able to capture screenshots and videos with just configuration settings is truly convenient.

Selenium is a great tool that pioneered web‑browser automation. I personally relied on it for many years.

However, the test‑automation landscape is changing:

• Browser differences have decreased, relatively lowering the importance of cross‑browser testing.
• Role‑based selectors enable more stable tests.
• Auto‑waiting frees us from flaky tests and wasted wait time.
• Most importantly, Playwright is designed as a “test automation platform,” not just a “browser automation tool.”

For those just starting with web test automation, or those considering migration from Selenium, I highly recommend Playwright.

This article is Part 1 of the Playwright series

Originally published at Arrangility.com.