Breaking through the Salesforce Shadow DOM

Salesforce is one of the most popular applications used across enterprises. It is known for its cloud-based releases, highly customizable nature, and deep integrations to a wide ecosystem of apps.

Organizations use Salesforce for a variety of different scenarios, not only for its customer relationship management (CRM), but for all facets of business functions including marketing, sales, customer support, supply chain, and finance. New product updates are automatically released to the cloud by Salesforce, multiple times a year. Customers bear the responsibility to test Salesforce to ensure that their customizations and integrations are intact and don’t break due to new updates.

Salesforce is a business-critical application where an outage or high severity bug can cost millions of dollars. To keep up with Salesforce’s cloud releases, it’s imperative for organizations to automate their regression tests. Yet, Salesforce is one of the tougher applications to automate due to several technical factors. 

First, Salesforce uses what’s called a Shadow DOM to encapsulate the internal document object model (DOM) structure of a web component. This encapsulation was intended to protect components from code manipulation and make it easier for developers to share reusable components across teams. However, a negative side effect of this approach is that the components aren’t recognizable for traditional test automation tools like Selenium. These tools rely on selectors (like the ID or Xpath) to identify objects. Since the Shado wDOM shields the underlying component, elements within cannot be found by these selector-based tools.

Second, even outside of Shadow DOM components, dynamic elements and iframes are difficult to recognize with traditional test automation tools. Selenium and most test automation tools rely on selectors (like the element ID or Xpath) to identify elements. This approach simply does not work with Salesforce since an element can have one ID today and have a completely different ID tomorrow. 

For these reasons, it’s no surprise that most companies test Salesforce completely manually. This means that key members of the business (eg. Sales operations personnel) are often pulled into hours of user acceptance testing (UAT) activities multiple times a year.

Luckily, Functionize has a solution for testing Salesforce. Functionize helps teams of all skill sets automate functional UI tests. We use a completely different approach to identify elements in automated tests. Instead of hard-coded selectors, Functionize collects large amounts of data and uses deep learning to intelligently identify elements. More specifically, hundreds of attributes are collected per element when a test is created and every time a test runs. We collect data from applications, not just for the target element of each test step, but for all elements on the page. This allows Functionize to accurately identify Salesforce elements even if they are dynamic, part of iframes, or even encapsulated by the Shadow DOM.

To address the Shadow DOM specifically, Functionize engineers built a script called “site stats.” This proprietary script exists behind-the-scenes in Architect, our smart recorder. So, while the test is being created, Architect records rich contextual data from the site and creates a custom representation of the DOM. As described previously, these hundreds of attributes per element (captured for every element on each page for every step) amounts to tens of millions of data points. We call this “ML data” since it feeds into our machine learning models. This “site stats” script also runs behind-the-scenes during test execution.

While the test runs, another tens of millions of data points are captured and fed into the machine learning models.

All of this big data captured from the Salesforce Shadow DOM allows Functionize to build a custom representation of the DOM. So, even if Salesforce Lightning web components are encapsulated, we still treat the Shadow DOM test like any other test. There’s no need to keep track of element CSS or Xpath selectors, and there’s no need to use code. This custom representation of the DOM means that Functionize finds scenarios where the ShadowDOM exists. When the ShadowRoot is found, the main top-level HTML and all ShadowRoot elements are combined so we can re-stitch together the application. The idea here is to re-create what the DOM would look like if there wasn’t a ShadowDOM at all. This allows us to consider every element on the page by running the machine learning models so that tests can run and identify elements successfully. 

We take this big data approach so that elements are recognized, no matter the UI framework. Functionize tests will keep up with changes to your application UI, even as Salesforce moves towards a LightDOM approach to ease challenges with the Shadow DOM. 

Since Functionize doesn’t rely on code to create tests, testers of all backgrounds can contribute to automating Salesforce tests. So, business testers can cut down the hours of their UAT efforts considerably. With the Functionize platform, you can create automated tests without code and run thousands of tests in parallel. We allow unlimited users to be invited to create an unlimited number of tests. This means that a regression cycle for Salesforce testing can be accomplished in days not weeks, and you can ensure that your Salesforce features are working release after release.