Top difficulties Selenium Automation is a challenge for Salesforce Lightning Development

Salesforce is the most popular CRM software in recent years, with a global market share of 19.5 percent in 2018. That's more than double the next closest competitor, SAP, and more than three times Oracle. The company has been able to target enterprise application development with its own Apex object-oriented programming language and Salesforce Lightning Consultant Web Component framework.

Salesforce allows developers to abstractly define business logic and user interface elements so that Salesforce can implement them on the page. Because developers have no direct control over the browser's final content, this flexibility comes at the expense of UI test automation. With open-source automation frameworks like Selenium, Salesforce enterprise apps are notoriously difficult to test.

Salesforce Lightning Selenium Automation is a powerful tool for automating browser user interactions. A well-designed Selenium framework can help you increase test coverage and save time. Many organizations, including Salesforce, use Selenium to automate their application testing.

You might want to use Selenium to automate your Salesforce application testing, especially when manual testing is insufficient to meet your regression testing needs. However, Salesforce applications are often complex and challenging to test with Selenium.

Ø Here are the top three Selenium scripting testing challenges for Salesforce test automation.

·  Getting around the frames

Salesforce Developer Lightning is a complicated application with a front-end built with dynamic frames that can independently load content in the current HTML document. Selenium has a hard time handling frames because it can't access the content directly. You'd have to use an attribute to switch the Selenium WebDriver to the frame.

Selenium can handle frames, but it takes a lot of effort to find the right attributes and script them correctly. When dealing with nested or hidden structures, it becomes even more tedious. A typical 30-50 step test case can take hours of coding and usually results in a brittle script due to the application's many frames.

·  Using dynamic content to execute

Like most modern web applications, Salesforce uses dynamic elements with no fixed ID, name, class, or CSS attributes. As a result, the element's locator cannot be hard-coded. Normally, the locator's fixed portion is difficult to detect using a standard method. Minor UI changes can cause the tests to become unstable. Furthermore, Selenium may experience synchronization issues when loading elements. Because most elements are dynamically loaded, the test script must include Implicit, Explicit, or Fluent Waits.

·  Table handling

Different database-driven tables can be used in Salesforce applications. The rows are dynamically generated and can be controlled by various tabs. As a result, simple actions like checking a Selenium checkbox can be tricky and error-prone. It cannot be easy to choose the active tab. Driver. Switch to. Window and send keys, for example, may not work reliably.

·  Other difficulties

Salesforce applications can contain complexities such as Shadow DOM and pop-up windows, which Selenium cannot easily test. Selenium does not directly support such elements, necessitating extensive custom coding. Testing any complex application presents challenges such as test case maintenance.

Though most of the challenges of Salesforce testing with Selenium can be overcome, scripting takes a long time. This may have an impact on your continuous testing objectives.

Ø Stable Selenium Tests for Salesforce Lightning Automation Testing

As a test engineer or developer, you want to know that your Lightning UI automated UI tests are accurate and only fail if there is a real regression.

·  The Situation

The scenario when a test attempts to communicate with an aspect on a page in the browser before the component has fully loaded is all too familiar to UI Test Automation engineers. A test failure occurs when an exception is thrown. Investigating and correcting a "false positive" takes time, resources, and a certain amount of nerve. This is a significant cost factor in UI test automation.

·  The Alternative

Selenium WebDriver includes a few influential wait functions by default. Unfortunately, not every tester or developer makes good use of them. Let's look at how we can use them to test the Lightning UI effectively. We'll also demonstrate that the widely used Sleep calls are only necessary for specific situations and can be safely removed in all others.

Ø Wait for functions in Selenium WebDriver

Selenium WebDriver offers three different types of waits:

·  Wait Implicitly

·  WebDriverWait – Explicit Wait

·  Explicit vs. Fluent Waiting (Java only)

C#, Groovy, Java, Perl, PHP, Python, Ruby, and Scala are just a few popular programming languages that Selenium WebDriver can use. Because FluentWait is only available in Java, the code samples in this article will be limited to that language.

·  Wait Implicitly

Setting implicit wait tells Selenium WebDriver how long to look for an element that isn't visible right away on the page. The driver, of course, does not "sit around" for the specified number of seconds but instead poll results on the page until it finds the element. If the aspect is not found within the time limit, the driver keeps throwing an exception.

·  Webdriverwait – Explicit Wait

The term "explicit wait" refers to the ability to define a wait for a specific condition to occur before continuing with the test.

Data from third-party data sources, such as a legacy database, is a common scenario in Salesforce applications. In this case, the Salesforce application has no control over the external system's responsiveness, so you'll see a message that says "Loading..." before the data appears in the browser.

Another typical scenario is that a button is disabled until background activities are completed, and then the button must be enabled after the activities are completed.

·  Explicit vs. Fluent Waiting (Java only)

The FluentWait class is only available in the Java version of Selenium WebDriver to match the ease of use of WebDriverWait in other programming languages. You can use FluentWait to tell the WebDriver instance to wait for a specific condition to occur and check for it at a specified frequency and ignore specified exceptions while waiting. While the WebDriverWait class does not provide these options, the FluentWait class does.

Ø When Should You Use Sleep Calls?

All of Selenium's supported languages have a call to suspend execution for a set amount of time. We'll use Java in the code examples to keep things simple, but the information applies to them.

·  Overuse of Thread.SLEEP

While not specific to Selenium WebDriver, Thread. Sleep () is a standard Java method that you'll find in many test projects. The call does precisely what it says: it suspends a test for a specified period of time.

·  Thread.sleep used correctly ()

Should you altogether avoid using Thread. Sleep () in your test projects? No, no, no. In some cases, you only need to bridge a brief period of time, such as a second or two, for the Lightning UI to enter the desired state. In this case, a one- or two-second Thread. sleep() call is preferable to a complex FluentWait or WebDriverWait call that spans several lines of code and is difficult to read or maintain.