Salesforce Application Test Automation
If you’ve ever tried using Selenium to automate testing of a Salesforce application, you probably know how daunting it is.
Selenium is an amazing tool for automating testing of browser applications. However, Salesforce apps are more complex than most web apps because they use shadow DOM and dynamic elements, including iframes.
Without a proper framework with lots of native code, Salesforce test automation is a nightmare!
However, do not worry: I found free a tool with built-in support for Salesforce automated testing.
But before we get to it, let’s take a look at some of the issues that you are most likely to run into when automating your test. Salesforce and similar software solutions.
Almost nothing annoys an automation engineer more than a user interface with dynamic elements that change their locators each time a test script is run.
This is the norm for Salesforce-based apps.
One run can have an identifier
gino1, and in the next one already
It is simply impossible to detect any logic or pattern of changing names. Names change dynamically and in unpredictable ways.
What do we do?
It is possible to devise a sophisticated strategy for defining element locators in which multiple elements are stacked together to identify a field, but even this strategy will be unreliable in some cases.
The problem is further compounded when the application under test contains dynamic iframes.
Iframes (inline frames) are HTML documents embedded in another HTML page.
Iframes are used to insert content from an external source into a web page, such as a podcast player:
Iframe is difficult to work with because Selenium needs to identify elements in a frame, which is not always an easy task.
Not every engineer is capable of writing code to handle this situation.
Selenium can switch between multiple iframes using the driver command switchTo (). frame…
//Store the web element WebElement iframe = driver.findElement(By.cssSelector("#modal>iframe")); //Switch to the frame driver.switchTo().frame(iframe); //Now we can click the button driver.findElement(By.tagName("button")).click();
This is all great, but I have found that few automation engineers know how to use these methods with maximum reliability.
Aside from iframes, there is one other thing that can be tricky for test automation – shadow DOMs.
One of the popular trends in modern web component development is the use of shadow DOM.
In this case, automation can be problematic, as this approach allows connections between standard DOM elements and hidden DOM trees, which means that many elements cannot be reached explicitly by creating a point-and-click script.
Developers often add their own HTML tags as well.
Selenium cannot directly identify such HTML tags in the shadow DOM.
There are plugins that can help in this matter, for example shadow-automation-selenium…
But again, applying them requires additional effort. You will need to add the library to the Maven POM file and learn the necessary syntax.
Such approaches can place a heavy burden on the shoulders of an automation novice.
Of course, you can write code to overcome most of these difficulties if you have the time.
But I know engineers who devote a lot of time to this problem and still cannot come up with a final solution.
How do you look at the option to solve the described problems with a free testing solution?
I just found one such solution – it is called TestProject…
Testing Salesforce Apps with TestProject
Eldar Kravetsky, CTO and co-founder of TestProject, told me that Salesforce-based applications were a great subject to experiment with when developing a new and improved test case recorder. The TestProject developers realized that if they can automate Salesforce testing, then their recorder will probably be able to automate anything.
Many of the problems associated with automating Salesforce testing and solved with TestProject also apply to other applications developed in codeless environments such as SAP, ServiceNow, etc.
As I mentioned earlier, you can write your own tests in Selenium or directly in TestProject, but not everyone has the necessary skills.
On the other hand, you can simply use the new recorder, which will surmount all difficulties unnoticed by you and allow you to create the necessary automation scripts.
So how does TestProject deal with the problems mentioned above that are inherent in applications like Salesforce?
How does TestProject work with iframe?
Selenium has the concept of context.
First, you need to switch to the iframe, and then keep track of which context your script is running in at any given time.
TestProject tracks this automatically and ensures that commands are dispatched to the correct context without having to write code to do so.
The recorder records every action you take in your application with iframes. When executing tests, it will automatically recognize the desired iframe to which it needs to switch.
No additional code is required, so you don’t have to worry about it while recording your test script.
TestProject is built on top of Selenium and Appiumso he knows how to use and extend the Selenium API methods without user intervention.
When I worked in a large enterprise with eight sprint teams, they always created flaky tests because they didn’t know how to write the code correctly to properly handle the context change situation in the test script.
If you’re an intermediate or advanced automation engineer, don’t worry: this is not some black box.
At each step, there are advanced settings available where you can see if any additional context exists, such as an iframe.
Thus, you have access to advanced control options if you need to adjust or change something during the setup process.
How does TestProject work with shadow DOMs?
The new TestProject recorder is also capable of handling shadow DOMs, which are heavily used in Salesforce and other applications.
In the case of shadow DOM, you usually see one element first, and when you move the cursor, the other. Therefore, even if you record your actions, you will not be able to reproduce them, since the necessary elements disappear.
In most cases, TestProject’s recorder handles these situations automatically for you.
The TestProject recorder handles all of the shadow DOM interaction in the background – you don’t have to worry about anything.
How does TestProject work with dynamic elements?
TestProject also makes it easier to write test scripts for applications that generate dynamic items that change with each run. Salesforce apps are again an example of this.
When faced with the challenge of testing a Salesforce application, you quickly realize that most of the items you test are dynamic. If you try to run your test again, it will not work because all IDs will change.
Check out the video I recorded. In it, I demonstrate the capabilities of an AI recorder to handle dynamic values.
At runtime, the recorder handles any changes to item IDs using AI power. This allows you to define the desired fields for interaction and avoid crashes.
Why is it useful to use TestProject?
If you know how to program, you can write any test program.
You can do whatever your heart desires. And if everything is done correctly, the result will probably please you for a long time.
But again, this takes skills that not everyone has.
And if you write the code yourself, it will take you a lot of time to automate what you need.
The guys at TestProject have put all their knowledge and experience into a solution to handle the automation of dodgy programs like Salesforce so you don’t have to worry about things like shadow DOMs, dynamic elements or pop-ups.
Why not save some time and rack your brains in vain? Try this solution and share your thoughts.
Anyone who is interested in teaching testing is invited to familiarize yourself with our courses, which have a special offer right now: