• Image 01

    Launch you Salesforce journey with us!

  • Image 02

    Welcome to the family!

  • Image 03

    Connect with Salesforce Ohana!

  • Image 04

    Hurdle through the challenges!

  • Image 05

    Push your challenges away!

  • Image 06

    Connect with other Salesforce professionals!

The Challenges of Salesforce Lightning Test Automation

Home > Salesforce Lightning
May 1 | By Krupa Shree | Views: 161 | Comments: 0
The Challenges of Salesforce Lightning Test Automation

Being an extensively accepted CRM application by over 150,000 companies, Salesforce has gained its customer's trust by providing 'Salesforce customer 360' experience that includes simplified sales processes, organized customer support, managed unified marketing platform, and a lot more.


As the Lightning Experience gains traction among Salesforce customers, many organizations have made a move towards the new UI.
It is a thrilling journey to the entire team including salesforce test engineers.

 

With all these personalized experience quality plays a key part in any major/minor releases. Automation testing, which is the most active and the highest-demanded way of testing, can make your life easier by taking over monotonous and repetitive test cases, as well as test the test pyramid levels that can’t be covered manually. As a consequence of this transformation, there is an impact on test maintenance. Because of these improvements, there is a change in Document Object Model (DOM) structure, tests that rely on specific implementation details in the DOM tend to break and require a revisit. 

 

I often hear the biggest task of Salesforce testing is that you need to recreate all your classic tests for the Lightning UI

As a test engineer or a developer, we want to be able to trust that our automated UI tests for Lightning UI are accurate and fail only if there really is a regression. The major cost driver for UI would be: when a test attempts to interact with a component on a page even before the component has been completely loaded resulting in a test failure alongside eating up time and resources


A solution to the above-stated problem would be to simply wait for the components are loaded fully. Well, it's not Thread.sleep(), which suspends a test for a specified amount of time but also there are chances of needless wait time even though the application is all ready making the test unnecessarily slow


Better would be to use the 'Wait' function by Selenium WebDriver.


Selenium WebDriver allows three types of waits: Implicit Wait - defines how long to wait when searching for an element that is not immediately present on the page. Explicit Wait (WebDriverWait) - defines a wait for a certain condition to occur before proceeding further in the testFluent Wait - defines the maximum amount of time to wait for a condition, as well as the frequency with which to check the condition. 


By introducing explicit wait statements and reducing unnecessary sleep calls from the test projects, we are more likely to achieve: 
Higher test pass percentages without re-runTest failures are more likely to be a sign of a real issue. Fewer resources wasted on triaging false positives. Reduction in overall test execution time Delays introduced due to events like waiting for a response from a call to web-services or a third-party database are handled in an efficient, yet robust manner.

Another fact is Lightning Web Components makes use of Shadow Document Object Model (Shadow DOM), one of the key browser features that ensure separation between the components without affecting each other.  Style encapsulation, the feature that gives shadow DOM it's power has been a bit of a pain when it comes to UI testing. Things just got a little easier though, as WebdriverIO v5.5.0 introduced built-in support for shadow DOM via two new commands, shadow$ and shadow$$.


With changing page structure in DOM, we need to adapt page object pattern where we can create an object having necessary elements and methods defined of the UI to be tested. This object helps to wrap HTML elements and encapsulate interactions with the UI. so all the calls to webdriver are pointed to page object making test UI less fragile.

 

The classic theme was extremely easy for extracting CSS selectors and XPaths while the same in lightning gets little harder got find selectors because of DOM content, CSS selectors and XPaths have dynamic values attached


To make it more effective while fetching XPaths we can use : Nested Custom locatorsUse of XPath functions like contains, parent, ancestors, following-sibling, etc. to find the related elements.


There are a handful of Chrome extensions available to make the job easier. you can choose wisely the one which best suits your customized application.


Salesforce most likely changes the DOM in each release. HTML, CSS, and the DOM in Lightning Experience can change at any time However, in Spring '20, you were needed to make some of these changes.


Replace WebDriver’s click() method with a JavaScript call. Revise your test strategy for combo boxes (also known as picklists). Revise your test strategy for locating elements that have moved into the Shadow DOM.App Launcher opens a picklist of all the Apps, not a dialog box.

 

While we all are waiting for the new features that Salesforce would delight us with, in Summer'20 Release. Let's all continue to ensure that the Salesforce Lightning instance meets performance expectations in terms of response time, concurrency, availability, and scalability.


Hope you found this article helpful!


References:
UI Test Automation on Salesforcehttps://developer.salesforce.com/blogs/2020/01/ui-test-automation-on-salesforce.html

Share:
No comments
You need to sign in to comment