iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
Reliable Salesforce Lightning end-to-end tests should verify user-visible workflows, not treat the rendered HTML as a compatibility contract. Use Jest for individual Lightning Web Component behavior and reserve Selenium WebDriver or similar UI automation for complete workflows. Keep authentication on an authorized, supported path: Salesforce’s MFA functionality does not accept one-time passcodes delivered by email, SMS, or phone calls.
Why does Salesforce Lightning automation break when the DOM changes?
Lightning Experience’s rendered HTML, CSS, and DOM structure can change without being backward-compatible. A test that locates an element by relying on a particular internal tag, class, nesting pattern, or component implementation may therefore break even when the user-facing workflow still works. Salesforce explicitly describes this markup as unstable and warns that tests reaching into component internals require maintenance. Salesforce Developers’ end-to-end testing guidance is the relevant reference.
This does not mean every UI test is a bad test. It means the test should assert the behavior that matters to the user, while minimizing assumptions about how Lightning happens to render that behavior. For example, a workflow test should verify that an authorized user can complete the intended task and see the expected outcome, rather than asserting a component’s private markup or implementation details.
Should you use Jest or browser-based end-to-end tests?
Choose the test layer based on what you need to prove. Salesforce recommends Jest for unit-testing individual Lightning Web Components and UI tools such as Selenium WebDriver for end-to-end testing. Browser automation is useful for integrated workflows, but it is a slower, more maintenance-sensitive way to test isolated component logic.
| Test layer | Best fit | What it does not establish |
|---|---|---|
| Jest component test | Component-level behavior and logic, tested without driving a complete Salesforce user workflow. | That the full browser workflow, org configuration, and user permissions work together. |
| End-to-end UI test | A user-facing workflow across the rendered Salesforce interface, using a UI tool such as Selenium WebDriver. | That Lightning’s internal HTML or DOM structure is a stable API. |
These roles follow Salesforce’s LWC testing recommendations. Keep most component-specific checks at the unit-test layer; use end-to-end tests for a smaller set of important user journeys that need the real interface and integration points.
Why can’t Selenium find an element inside a Lightning component?
Lightning Web Components use Shadow DOM to encapsulate component markup. A page-wide DOM query does not necessarily reach elements inside that shadow tree, so a selector that finds an ordinary page element may fail when applied to content owned by a component. Salesforce explains that end-to-end tests can adapt by querying a component’s shadowRoot from client-side code, but accessing internal markup creates coupling to implementation details.
Use this order when diagnosing a missing element:
- Confirm the user-facing state. Check that the page, record, component, and expected control have actually loaded for the authorized test user.
- Check the component boundary. Determine whether the target is in a component’s shadow tree rather than assuming a global selector can reach it.
- Prefer a user-facing interaction. Where the test tool and page expose a stable way to identify the control by its visible role or purpose, use that rather than a selector tied to internal structure.
- If internal access is necessary, make the dependency explicit. Treat shadow-root traversal and any internal selector as a maintained test seam. Revisit it when Salesforce, the component, or the org changes.
- Separate a selector failure from an application failure. Verify whether the control is missing or whether the test simply cannot reach it through its current query path before changing application code.
Shadow-root access can solve a query problem; it does not turn the component’s internal DOM into a supported, stable test interface. Salesforce’s warning about DOM changes still applies.
Free tools Windows power users keep installed
One-click scans. No signup required.
How do Locker and Lightning Web Security affect DOM access?
Salesforce’s DOM containment guidance says a component can traverse and access only DOM that it created. The exact access boundary depends on the security model and browser DOM behavior, so a test or component should not assume it can inspect another component’s private tree. Salesforce distinguishes Lightning Locker, Lightning Web Security (LWS), and browser Shadow DOM in its DOM access containment guidance.
Rank #3
| Area | What to account for | Practical implication |
|---|---|---|
| Component ownership | A component is limited to traversing and accessing DOM it created, under Salesforce’s containment guidance. | Do not build component logic or tests around unrestricted access to another component’s internals. |
| Locker and LWS | Salesforce documents different containment behavior for Lightning Locker and LWS. | Validate tests and component behavior against the security model actually configured for the org. |
| Enabling LWS | Salesforce says LWS is generally available and enabled by default for newer orgs; existing or packaged components should be tested in a sandbox before enabling it in production. | Use a sandbox to check compatibility before an org-level security change. See Salesforce’s guidance on when to enable LWS. |
Org configuration matters: a test that passes under one security model is not proof that the same component behavior will hold under another. Keep the tested org’s configuration visible in test setup and triage notes.
Which MFA methods can an authorized Salesforce test account use?
Salesforce documents built-in authenticators, authenticator apps, and physical security keys as MFA verification methods, with phishing-resistant options preferred in its current guidance. Importantly, an authenticator-app code is not the same as an OTP delivered through email, SMS, or a phone call. Salesforce states that its MFA functionality does not allow security questions or one-time passcodes delivered through those channels. Check the current Salesforce list of supported MFA verification methods when configuring a test org.
| Method | What Salesforce’s guidance establishes | Test-planning consideration |
|---|---|---|
| Built-in authenticator or authenticator app | These are among the verification methods documented by Salesforce. | Plan the authorized test-user setup and verification step; do not assume an email- or SMS-delivered code is a supported substitute. |
| Physical security key | Salesforce documents WebAuthn/FIDO2- or U2F-compatible keys and names YubiKey and Google Titan as examples. | Confirm the specific key, browser, org domain, and admin configuration work for the target org before making it part of the test setup. |
For security keys, Salesforce says administrators must enable keys for non-privileged users. Its documentation also flags that orgs on domains other than salesforce.com and force.com do not currently support U2F keys. Because key and domain compatibility can be configuration-dependent, verify the current Salesforce security-key guidance for the specific org rather than assuming a model will work everywhere. A security key is a verification factor, not a way around an MFA challenge.
How should you keep Salesforce UI automation secure?
Run end-to-end tests only with accounts and orgs you are authorized to use, and follow the organization’s approved login and MFA configuration. Do not design automation to evade or defeat MFA. If interactive verification makes a workflow unsuitable for unattended UI testing, choose an organization-approved test setup or a supported Salesforce authentication flow rather than weakening the control.
Best Value
Also keep authorization enforcement on the server. Salesforce’s secure-coding guidance treats the client as under attacker control and says access checks must happen server-side. A passing browser test, hidden control, or client-side component check is not a substitute for permissions or server-side CRUD and field-level security checks. See the Lightning Security Secure Coding Guide.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
