I’ve been dealing with this for months now. We have a solid suite of Playwright tests, but the moment our design team tweaks anything—a button moves, a class name changes, an ID gets refactored—everything falls apart. We’re spending more time fixing broken selectors than actually writing new tests.
I know the standard advice is to use better locators and avoid brittle selectors, but that only gets you so far. The real issue is that maintaining these scripts as the UI evolves feels like a never-ending game of whack-a-mole.
I’ve heard there are ways to generate more resilient test workflows using AI, but I’m skeptical about how well that actually works in practice. Has anyone here actually gotten that to stick, or does it just shift the problem around? I’m curious if there’s a fundamentally different approach to this maintenance headache that actually scales.
This is exactly where AI-generated workflows shine. Instead of hand-coding selectors that break, you describe what the test should do in plain language. The AI figures out the locators and adapts them as the UI changes.
I’ve seen teams cut their maintenance time in half because they’re not constantly chasing selector updates. You write once in plain English, and the workflow stays stable even when the UI shifts.
The key is using a tool that understands context, not just pattern matching. Latenode’s AI Copilot generates Playwright workflows from descriptions and rebuilds them intelligently when things change.
Check it out: https://latenode.com
I hit the same wall a couple years back. The thing is, brittle tests aren’t really a Playwright problem—they’re a design problem. You’re fighting against the natural entropy of UI changes.
What helped us was shifting from managing test code to managing test intent. We stopped thinking about selectors and started thinking about what the test actually validates. Once you separate those concerns, maintenance becomes way less painful.
That said, there’s definitely value in tools that can regenerate parts of your workflow when the UI shifts. You still need to own the logic, but at least you’re not manually hunting down every broken selector.
Have you tried using data attributes specifically for testing? Add a data-testid to elements you care about and reference those instead of class names or IDs. It doesn’t solve the UI moving around, but it does reduce how often things break from styling changes.
Beyond that, I’d look at whether you’re testing too much UI detail. A lot of brittle tests are brittle because they’re asserting on implementation rather than behavior. When you shift to outcome-focused tests, changes matter less.
Your pain point is common, and it stems from how Playwright works at the selector level. Every locator you write is context-dependent, and UI changes inevitably break that context.
Some teams have found success with AI-assisted workflow generation because the approach is fundamentally different. Instead of maintaining selector code, you maintain descriptions of what should happen. The system handles the mechanics of finding elements and responding to layout changes.
That said, this only works if your test workflows are well-structured and your descriptions are clear. Otherwise you’re just moving the maintenance burden elsewhere.
Generate tests from descriptions instead of selectors. Less maintenance when UI changes.
This topic was automatically closed 24 hours after the last reply. New replies are no longer allowed.