Playwright · 6 min read

Playwright Selector Strategy for Salesforce Lightning Components

The 4 selector types ranked by stability, with real examples for Lightning components.

Salesforce Lightning's shadow DOM and auto-generated class names are the single biggest reason Playwright suites break on seasonal releases. Not all selectors degrade equally — here's how we rank them, most stable to least.

1. Data Attributes (Most Stable)

Where you control the component (custom Lightning Web Components), data-testid or similar attributes survive nearly every release, since they're not tied to Salesforce's internal styling or DOM structure.

2. Accessible Role + Label

Selecting by ARIA role and accessible name (e.g., a button with a specific label) is close behind — Salesforce rarely changes accessible names since doing so would break its own accessibility compliance.

3. Stable Field/Object API Names

For standard and custom fields, selecting via the underlying API name (rather than the displayed label, which can be translated or renamed) holds up well across releases, though it requires deeper Salesforce metadata awareness to set up.

4. DOM Position or Generated Class Names (Least Stable)

Auto-generated classes and nth-child/DOM-position selectors are the most common cause of post-release breakage. Salesforce's Lightning framework regenerates these on nearly every seasonal update. If your suite leans on these, expect the 20–30% breakage rate we see across most client audits.

What We Actually Do

On every Playwright engagement, we audit the existing selector mix first and re-prioritize toward data attributes and accessible roles before touching anything else. It's usually the highest-leverage fix available — more impactful than adding new tests.

Suite Breaking Every Seasonal Release?

We'll audit your selector strategy and tell you exactly what to fix — free, as part of your trial.

Get a Free Audit →