How To Do Salesforce Test Automation

If you’ve ever tried using Selenium for salesforce test automation you know it can be challenging.

Selenium is a fantastic tool for automating browser applications.

But Salesforce adds extra complicity that's not found in most web applications, like Shadow DOMs, dynamic IFrames, and dynamic elements.

Without a proper framework with lots of custom code, salesforce test automation is a nightmare to get right.

No worries, though, because I’ve found a free tool with Salesforce automation support built-in.

But before we get to that, let's take a look at some of the issues you’re likely to encounter when automating Salesforce and similar software solutions.

Dynamic Elements

Not many things are more annoying to an automation engineer than a UI with dynamic elements that change their locators with every test script run.

Salesforce-developed applications are a habitual offender in this department.

In one run, the ID might be gino1 and in the next run, gabagool5.

There’s no rhyme or reason for the name change. The changing names tend to be dynamic and indeterministic.

So what do you do?

You can develop a complex element locator strategy that stacks multiple elements together to identify a field, but even this strategy can be unreliable at times.

The issue becomes even worse when the application under test also has dynamic IFrames.

IFrames

IFrames (also known as inline frames) are HTML documents embedded into another HTML page.

You use IFrames to insert content into a web page from an external source, like this podcast player:

IFrames are tricky because Selenium needs to identify the elements under the frame, which is not always an easy feat.

Not everyone has the skill set to code for this situation.

Selenium has a way to handle switching back and forth between IFrames using the driver's switchTo().frame command.

//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 fine, but I've found that not many automation engineers know how to use these methods for maximum reliability.

In addition to Iframes, something else that can trip up an automation test is Shadow DOMs.

Shadow DOMs

One of the trends of building modern web components that are becoming popular in software development is Shadow DOMs.

Automating this can be problematic since this technique allows hidden DOM trees to be associated with elements in a standard DOM, which means that many elements are not readily available for creating a “point and click” type of script.

Developers also frequently add custom HTML tags.

Selenium can't directly identify custom Shadow DOM HTML tags.

Of course, you might be able to get around certain Shadow DOM/Selenium issues using the JavascriptExecutor method, but it is tedious, hard to maintain, and adds over-complexity to your script.

There are also some plugins you can use, like shadow-automation-selenium.

But once again, this takes extra effort. You need to add the library to your Maven Pom file and remember the syntax to use.

Techniques like this can be a burden on a new automation engineer.

Yes, you can code a solution to overcome most of these if you have time.

But I've known engineers who devote lots of time to this problem and still fail.

What if there were a way to handle these issues with a free testing solution?

I’ve just found one called TestProject.

Testing Salesforce with TestProject

Eldar Kravetsky, CTO and co-founder of TestProject, told me that Salesforce was a great case study for TestProject's new enhanced test recorder because they came to understand that if they can automate Salesforce, then the recorder would probably be able to automate anything.

So many of the issues related to automating Salesforce that TestProject works around, also applies to other applications developed in codeless applications like SAP, ServiceNow, etc.

As I mentioned earlier, you can write your own coded tests in Selenium or directly in TestProject to begin with, but not everyone possesses that skill set.

On the other hand, you could just use the new recorder to handle all of these challenging automation scenarios for you in the background.

So how does TestProject handle some of the above issues we addressed earlier with applications like Salesforce?

How TestProject Handles IFrames

In Selenium, there is a concept of contexts.

You need to switch into the IFrames, and you need to handle what your script “context” is at any given point.

TestProject tracks this automatically and takes care of sending the commands to the correct context without having to code yourself.

The recorder will record each step in an application that uses IFrames. When executing your tests, it automatically knows to switch to the correct iFrame.

No extra coding is needed. The person recording the test doesn't have to worry about it.

They built TestProject on top of Selenium and Appium, so it's smart enough to know the Selenium API methods to use and enhance without user input.

When I worked for a large enterprise with eight sprint teams, they always created flaky tests because they didn't know how to code correctly to handle the test scenario's context switching needs.

If you are an intermediate-to-advanced automation engineer, don't worry – this is no blackbox.

In the advanced section of each step, you will see whether there is some other context, like an iFrame being used.

So, you have advanced control if you need to adjust or change something over time.

How TestProject Handles Shadow DOMs

The new TestProject recorder also handles shadow DOMs that are popular in Salesforce and other applications.

With a Shadow DOM you'll typically see one element, and when you move the mouse, you'll see a different element. So, if you record something it will fail when you run it since it's not there anymore.

In most cases, the TestProject recorder handles these situations for you automatically as well.

The TestProject recorder handles the shadow DOM interactions behind the scenes for you without you needing to worry about it.

How TestProject Handles Dynamic Elements

TestProject also simplifies the recording of test cases against applications that generate dynamic elements that change on every run, like apps in Salesforce.

If you were to create a test against Salesforce, you will quickly learn that the majority of the elements under test are dynamic. So, when you run your test it will fail, since all the IDs have changed.

To see this in action, check out the video I did showing how the AI recorder worked against dynamic values.

During runtime, the recorder handles any changes to the element IDs using AI to identify the correct fields to interact with without failing.

Pretty cool.

Why use TestProject?

If you know how to code, you can code anything.

You can do whatever you want. And if you do it right, it will probably work for a long time.

But again, it does require a specific skill set that not everyone has.

And if you are coding it yourself, it will probably take you more time to achieve what you need to automate.

The folks at TestProject have applied everything they know in order to tackle the automation of tricky
software like Salesforce so that you don't need to worry about things like Shadow DOMs, dynamic elements, or popups.

Why not save yourself some time and headaches? Give it a try yourself and let me know what you think.