Where Selenium is still used
Selenium's longevity means it is deeply embedded in many enterprise QA workflows. Organisations with large existing Selenium suites, internal Selenium Grid infrastructure, or QA teams with decades of Selenium expertise have a significant switching cost that is not always justified by the benefits of migrating.
Selenium also supports a wide range of programming languages — Java, Python, C#, Ruby, and others — which means teams outside the JavaScript ecosystem have more natural language options than they do with Playwright.
- Broad language support — Java, Python, C#, Ruby, and more
- Mature ecosystem with extensive tooling built over decades
- Well-understood in enterprise QA organisations
- Selenium Grid allows distributed test execution at scale
Where Selenium struggles by modern standards
Selenium's architecture requires a WebDriver server to sit between the test and the browser. This adds latency, creates an additional failure point, and complicates local setup. Modern alternatives like Playwright use the browser's native automation protocol directly, which is faster and more reliable.
Selenium's auto-waiting capabilities are significantly weaker than Playwright's. Teams using Selenium typically spend considerable effort on explicit waits, sleep calls, and retry logic to deal with asynchronous UI behaviour. This is a major source of flakiness and maintenance overhead.
Selenium tests are also verbose. The boilerplate required to write a basic Selenium test in Java or Python is substantially higher than the equivalent in Playwright or Assert, which increases authoring time and makes tests harder to read.
- WebDriver architecture adds latency and a failure point between test and browser
- Weaker auto-waiting requires manual waits and retry logic
- Verbose test code — high boilerplate for basic operations
- No built-in screenshot or trace capabilities
- Slower test execution than Playwright in most benchmarks
- Setup complexity is significantly higher than modern alternatives
What Assert offers instead
Assert runs on Playwright, which communicates directly with the browser via Chrome DevTools Protocol and equivalent protocols for other browsers. This removes the WebDriver layer entirely, which means faster execution, better reliability, and built-in support for modern web features like service workers, web components, and shadow DOM.
More significantly, Assert's Markdown scenario model means teams can define what to test in plain English and have the Playwright execution layer generated automatically. Teams migrating from Selenium do not need to rewrite their entire test philosophy — they can describe what they used to test in Selenium in readable scenarios and Assert handles the implementation.
When to consider migrating from Selenium
Migration from Selenium is worth considering when: your suite is spending more time on maintenance than on catching real bugs, flakiness has made the suite untrustworthy, setup and infrastructure complexity is slowing down new team members, or you want to integrate AI tooling into your testing workflow.
Migration does not need to be all-or-nothing. Many teams run Playwright or Assert alongside Selenium during a transition period, gradually covering new flows in the modern stack while letting the Selenium suite decline naturally.
FAQ
Is Playwright faster than Selenium?
In most benchmarks, yes — significantly. Playwright's direct browser protocol communication removes the WebDriver latency, and its built-in parallelisation is more efficient. For suites with hundreds of tests, this translates to meaningful CI time savings.
Can I reuse my Selenium test logic in Assert?
Not directly — the APIs are completely different. However, Assert scenarios are written at the user intent level, so you can describe the same test coverage your Selenium suite provides in readable Markdown and Assert generates the Playwright implementation. The migration is at the scenario level, not the code level.
Does Assert support Java or Python like Selenium does?
Assert scenarios are written in Markdown, which is language-agnostic. The Assert CLI and execution layer are Node.js-based, but the scenarios themselves are plain text files that any team member can read and edit regardless of their programming background.
Put the workflow in your repo, not in a chat transcript
Assert is strongest when scenarios become durable project assets: readable Markdown in the repo, generated execution underneath, and result inspection in the dashboard.