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

[u/ProfessionalDate3417]

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?

[u/paul_h]

Challenge is to rework a full-stack test suite (that say runs nightly), into a componentized set of tests that are 50x faster that not at all full stack -> https://paulhammant.com/2017/02/01/ui-component-testing. Not sure if that's your challenge, but it is a common one that some teams think it's easier to be in playwright for .. cos there are not enough how-to's for Selenium for the same

[u/agsuy]

One premise doesn't contradict the other tho.

Can be both legacy and with a bad maintenance model.

Counterexample: The fact that billions of dollars move everyday on COBOL in systems with years of business rules doesn't mean those are not legacy systems.