Login

r/selenium

▲ 7 r/selenium

What’s your go-to approach for Selenium testing?

I usually start with the smallest reliable layer, then use Selenium for the flows that actually need a browser.

I’m revisiting our approach because the suite is getting slower to trust as it grows. For people maintaining Selenium tests day to day: what’s your go-to setup for keeping tests readable and failures actionable?

Mostly interested in practical habits around waits, page objects or alternatives, test data, and deciding what not​ to automate in the UI.

reddit.com
u/sunnyWave8 — 2 days ago
▲ 8 r/selenium

Request to the Selenium Developers — Please Improve the Documentation

A sincere request to the Selenium developers and contributors:

Please consider making the official Selenium documentation more complete, clearer, and more consistently maintained so even a beginner can get the right understanding for them.

It would be extremely helpful if every major Selenium feature, API, configuration, and behaviour had clear documentation with:

  • Simple explanations of what it does and why it exists
  • Clear usage examples
  • Detailed API documentation
  • Configuration and setup details
  • Architecture and internal behaviour where relevant
  • Common use cases and limitations
  • Troubleshooting information
  • Migration guides for major changes
  • Proper, detailed changelogs for every release, for easy understanding.
  • Clear documentation of deprecated, changed, and removed features
  • Examples showing differences between Selenium versions
  • Documentation kept in sync with the actual implementation

In particular, proper changelogs would be very valuable. When upgrading Selenium, developers should be able to quickly understand what changed, what was fixed, what was added, what was deprecated, and whether any existing code may be affected.

Selenium is a critical project for the automation ecosystem. Having documentation that is as strong and detailed as the project itself would make it significantly easier for developers to learn, upgrade, troubleshoot, and use Selenium correctly.

This is simply a request to the Selenium team and contributors: please continue investing in clear, comprehensive, and properly maintained documentation and release changelogs.

Official website: https://www.selenium.dev/

u/saikat_j_das — 5 days ago
▲ 25 r/selenium

Our Selenium suite isn’t “legacy”. the maintenance model is.

we have a Selenium suite with a few thousand tests and every few months somebody suggests:

should we just rewrite this whole thing in Playwright?

because apparently Selenium became “legacy” the moment the frontend team renamed 40 components and 70 tests went red.

I don't think Selenium is the main problem.

our suite has years of actual business knowledge in it.

refund rules
permissions
weird account states
old bugs nobody remembers
customer-specific flows

throwing that away because another framework has nicer APIs feels insane.

the actual debt is more boring:

  • locators tied to DOM structure
  • giant Page Objects nobody wants to touch
  • sleep(3000) archaeology
  • five tests rebuilding the same login/setup flow
  • UI tests asserting things that belong at API level
  • tests for features that died two years ago
  • nobody owns anything

Playwright would make some of this nicer.

it would not fix a test nobody understands.

and honestly if the frontend can give us stable data-testid / accessible contracts, I'd rather do that than ask AI to constantly rescue broken CSS selectors.

where I do think AI gets interesting is the maintenance layer.

KaneAI/TestMu is taking a reasonable approach here: tests can be written around natural-language intent and broken UI locators can self-heal, but the changed mapping is reviewable instead of “AI clicked something vaguely nearby so green build 👍”.

that's an important distinction.

I don't want silent healing on a payment or permission flow.

show me:

old element
new element
what changed

then let a human decide whether:

“Approve withdrawal”

still means the same thing after the UI changed.

for boring cosmetic locator drift, great, save me the maintenance.

for business intent changes, fail loudly.

my current instinct for an old suite would be:

keep stable/high-value Selenium coverage
delete stale/redundant garbage
move lower-level assertions out of UI
heal/refactor maintenance-heavy useful flows
rewrite only when the rewrite actually buys something

not “new framework exists, therefore 4 years of regression coverage goes in the bin.”

for people modernizing big Selenium suites: are you rewriting, healing, or mostly discovering that half the suite should just be deleted?

reddit.com
u/ProfessionalDate3417 — 8 days ago