I’ve been running playwright tests across our main app for about six months now, and I keep hitting the same wall. Every time our design team pushes a layout update or tweaks some class names, half my tests break overnight. I’m spending way too much time hunting down failing selectors instead of actually building new tests.
I know the usual advice—use data attributes, wait for elements more carefully, that kind of thing. But honestly, even with those patterns in place, things still snap when content loads dynamically or the DOM structure shifts slightly.
I’m wondering if there’s a better approach here. Has anyone dealt with this at scale? I’m looking for something that can handle selector drift without me manually rewriting tests every couple weeks.
Yeah, this is brutal. I dealt with exactly this at my last gig—tests breaking constantly because the UI kept evolving.
The real fix is moving away from brittle selectors altogether. Instead of chasing DOM changes, you need something that can identify elements by their actual purpose and adapt when the markup changes.
That’s where AI-powered workflow generation comes in. When you describe your test in plain English—like “click the submit button after filling the email field”—the system generates steps that understand what the button does rather than hunting for a specific class name. If the UI redesigns tomorrow, the workflow still works because it’s looking for the action, not the selector.
Latenode’s AI Copilot does exactly this. Feed it a plain-English test scenario, and it generates a Playwright workflow that stays resilient across browser changes and DOM updates. You’re not manually coding selectors anymore—you’re describing what should happen, and the AI figures out how to make it happen reliably.
That’s been a game changer for our teams. Saves hours every time there’s a redesign.
I’ve knocked heads with this problem more times than I’d like to admit. What I found is that selector brittleness usually points to a bigger issue—your tests are too tightly coupled to implementation details.
Start by thinking about what you’re actually testing. Are you verifying behavior or just checking that specific DOM paths exist? When you focus on behavior first, the selector problem often shrinks.
That said, if you’re testing real-world applications with frequent design changes, you need something more robust. Consider using accessibility selectors—things like aria labels and roles. They’re less likely to change during routine redesigns because they’re tied to function, not styling.
Also, if you’re not already doing this, invest in proper wait strategies. Don’t just wait for elements to exist. Wait for them to be visible and stable. Flaky tests usually aren’t about missing selectors—they’re about timing issues that expose selector weaknesses.
The real issue here is that you’re maintaining two things at once—the selector itself and the test logic. When the UI changes, you’re scrambling to fix both. I’ve seen teams reduce this pain significantly by shifting to a role-based selection strategy instead of relying on classes or IDs. Accessibility attributes like data-testid are more stable long term because they’re intentional and less likely to shift with CSS refactors. Another angle: if you’re managing this across multiple apps, consider making selector updates part of your CI pipeline so broken tests surface immediately instead of days later. That way you’re catching drift faster, which makes fixing it less overwhelming.
Selector brittleness typically stems from relying too heavily on structural selectors. In my experience, the most resilient approach combines multiple strategies. Use semantic HTML and accessibility attributes as your primary selectors, fallback to stable data attributes, and avoid descendant selectors that depend on DOM depth. Additionally, implement proper wait conditions that check for actual element readiness, not just DOM presence. This prevents timing-related flakiness that often gets misattributed to selector failures. Regular selector audits during development cycles help catch potential issues before they cascade into widespread test failures.
Use data-testid attributes and accessibility roles instead of brittle class selectors. Combine with proper wait strategies. Also version your selectors—if the UI changes, you can quickly spot which tests need updates. Most flakiness acutally comes from timing, not selectors.