Salesforce has become the dominant CRM platform in recent years, with a 19.5% global market share in 2018. That is more than twice as much as SAP, the nearest alternative, and more than three times as much as Oracle. Its success comes from developing for enterprise applications with its own Apex object-oriented programming language and Lightning Web component framework.

Salesforce allows developers to define their business logic and UI elements in an abstract way so that Salesforce can implement them on the page. This flexibility comes at the expense of UI test automation because the developer has no direct control over what ends up in the browser. Salesforce enterprise applications are notoriously difficult to test using open source automation frameworks such as Selenium. Let’s take a look at some of the reasons why Salesforce enterprise apps are hard to test and how to fix them.

The challenges of testing Salesforce enterprise applications

Element identifiers are a common method used by Selenium to locate and automate Web page interactions. The @FindBy annotation in Selenium has a simple ID =”something “attribute to locate a Web element by its unique ID on the page.

Atypical element identifier

Element identifiers in Salesforce applications look very strange: for example, ID =”940:1376; A “. Worse than that, identifiers change randomly between page visits. This makes identifiers useless for test automation. Consider how Selenium tests should locate elements in the following example when the ID changes each time the test is run.

Tips and Tricks

The < input> element has no other uniquely defined attributes. Fortunately, Salesforce meets the latest web accessibility guidelines. Section 1.3.1 of the WCAG on information and relationships provides for associating human-readable < label> elements with their corresponding < input> in code by matching the “for “attribute of the label with the” ID “attribute of the input. The element identifier may change each time the page loads, but the tag text should always be the same.

In this example, the “company name” text is contained in an attribute of “940:1376; < label> of a “, which happens to match the identifier of the < input> element. Selenium tests can use a clever XPath to connect label text to input elements: //input[@id=//label[normalize-space(.)=’ company name ‘]/@for].

This XPath can locate any < input> element on the page, and its “ID” attribute is equal to the “for “attribute that displays the” company name “< label>. Normalized space (.) The XPath function removes the extra white space in the < span> element that wraps the text in this example. This makes Selenium testing seem more complex, but it gets the job done.

Slow cloud hosted enterprise applications

Despite its name, Salesforce’s cloud hosting of enterprise apps can sometimes be quite slow. Test automation engineers are familiar with the challenges of slow-responding applications. If the test script tries to execute the next step before the application is ready, it will fail.

Hard-coding a delay of a few seconds into the test may pause more than necessary most of the time and increase the overall time of the test run. In order for the delay to be long enough, the wait needs to be conditional. Salesforce makes the typical Smooth Selenium wait conditions difficult to use by loading the overlay mask by rendering on the page.

Selenium has built-in support for dynamic wait conditions. It checks for the presence or clickability of elements several times per second — at most once before making an error. The problem is that none of Selenium’s built-in wait conditions can handle the loading masks in Salesforce. Selenium detects that the element under the load mask does exist and is not disabled. It stops waiting and tries to click on it. This causes an exception because the click is intercepted by the load overlay.

Tips and Tricks

Not all hope is lost. With a few more lines of Selenium code, you can catch the click-blocked exception and try again using the same wait loop and timeout.

Remember and re-initialize the Lightning UI component

Another thorny issue with UI test automation is that Salesforce remembers which Lightning UI components were opened last and reinitializes the last known state at login. This means that the initial page layout available for testing changes based on the saved history.

Tips and Tricks

One way to reduce the impact of the previous state is to have the test launch the browser incognito. Selenium makes it easy for the Google Chrome browser to do this by passing options in the setup method of the test class.

The other options shown here disable the browser prompt for sharing the location with Salesforce because Selenium tests get stuck on this permission prompt during playback. Maximize the browser window to fit more elements on the screen. This also reduces the need to test scrolling to elements before clicking them. If the test does need to scroll down to an element further down the page, Selenium can execute this JavaScript command to do so.

Test the benefits of Salesforce enterprise applications using Selenium automated UI tests

These tips and tricks make it useful to automate UI testing for Salesforce enterprise applications using Selenium. Test automation is an important way to quickly detect regressions after changing business logic or Web components in enterprise applications. Salesforce itself releases changes several times a year. A set of Selenium tests is a great way to quickly check compatibility with the latest Salesforce updates in the sandbox before launching a production release.

Use AI technology to enhance Selenium automated UI testing capabilities

If these tips and tricks seem too cumbersome to put into action on your own, consider using Parasoft Selenic to effectively automate Selenium test creation and simplify test maintenance. Using Selenic, you can record interactions with Salesforce enterprise applications in a browser. Then you can easily create Selenium test classes that leverage all of these same techniques.

The Parasoft Selenic integrated Recorder provides an application selection, so you can choose to collect Salesform-specific properties while logging UI actions. Selenic then incorporates these attributes when creating Selenium UI tests and uses AI techniques to self-repair tests that are interrupted by locators or waiting conditions.