be_ixf;ym_201912 d_06; ct_50
image

Load Testing

Cloud Load Testing: New Challenges in Testing Salesforce Lightning

In 2016, Salesforce.com began marketing Salesforce Lightning: a new variation of their user interface that’s focused on ease of use and speed. The pre-existing UI, now dubbed “Salesforce Classic” is still available, but Salesforce intends to eventually move all customers to the new Lightning UI. 

You can’t talk about “ease of use and speed” today without addressing performance issues. How do you ensure that your Salesforce Lightning instance meets performance expectations in terms of response time, concurrency, availability, and scalability?

What is Salesforce Lightning vs. Classic?

For some quick background (feel free to skip ahead), Salesforce Classic is the famous appearance that the platform has become well-known for. It’s an easy and straightforward solution for Sales; however, it was relatively limited for new features that Salesforce looked to release.  In 2015, the interface was redesigned with the lightning theme, and that brought other functionalities and sophisticated features that came accompanied with simple wizard-style navigation helpers. Even though Salesforce has released this new option for the UI, it still offers both views for all customers, for the time being, so you can pick between them and choose the one you prefer.

Salesforce Lightning UI
Salesforce Classic UI

How should I measure the performance of Lightning vs. Classic?

There are a number of options for load testing cloud applications such as Salesforce.com. Traditionally, the best approach would be to simulate traffic at the protocol (HTTP) level.  In turn, we could measure the response time from Salesforce.com, typically using tools like JMeter or Gatling for each environment. 

One drawback of these tools is that they won’t reflect the render time of the user interface components seen by a real user, because traditionally these tools don’t load all of the elements in the browser needed to display the complete page.  A real browser is required to perform the task of measuring accurate page load time, and there are specific tools we recommend for that – such as Flood Element and Selenium.

What is Flood Element?

Flood Element is a load generation tool which uses the Google Chrome web browser in headless mode (via puppeteer) to generate load on a web application. By running Element in Flood, you can simulate thousands of browser instances running a predefined test script to simulate a series of user interactions. Flood Element test scripts are written in TypeScript and follow a very similar syntax to Selenium.

What did we observe when writing tests for Salesforce Classic vs. Salesforce Lightning?

Our main observations from trying to script a simple scenario to log in and add contacts, accounts, and opportunities: 

  1. We found out that the Classic theme was extremely easy for extracting CSS selectors and XPaths. These selectors are needed to define the object we want to perform an action on.
  2. We noticed that the code created to test Classic is more straightforward, which speeds up response times. On the other hand, the scripting for Lightning was more complicated, because the CSS and XPaths had sticky dynamic values that take time to execute in between step actions. We also realized that the DOM content contains more complexity and it was harder to find the definitions for the objects and that also delayed our tasks.

Here, we’ve got a comparison of the selectors available for the Classic UI vs. the options available when selecting objects with the Lightning UI:

Classic UI
Lightning UI

The impact on the scripting is that the process of finding objects in Salesforce Lightning can be much trickier than doing so with Salesforce Classic: 

Creating a New Account in Salesforce Classic

step(‘Test: 06 – Fill New Accounts’, async browser => {

await browser.type(By.css(‘#acc2’), account)
await browser.type(By.css(‘#acc10’), “9612338892”)
await browser.selectByText(By.css(‘#acc6’), “Prospect”)
await browser.selectByText(By.css(‘#acc14’), “Public”)
await browser.selectByText(By.css(‘#acc7’), “Other”)
await browser.takeScreenshot()

})

Creating a New Account in Salesforce Lightning

step(‘Test: 06 – Fill New Account’, async browser => {

await browser.type(By.xpath(‘//*[@id=”90:4449;a”]’), account)
await browser.type(By.xpath(‘//*[@id=”115:3831;a”]’), “9612338892”)
await browser.type(By.xpath(‘//*[@id=”4:3831;a”]/div/div[3]/div[1]/div/div/div/div/div/div[2]/div/ul/li[1]/a/span[2]’), “Antonio”)
await browser.selectByText(By.xpath(‘//*[@id=”311:3831;a”]/div/div/a’), “Prospect”)
await browser.selectByText(By.xpath(‘//*[@id=”357:3831;a”]/div/div/a’), “Public”)
await browser.selectByText(By.xpath(‘//*[@id=”407:3831;a”]/div/div/a’), “Other”)
let linkSaveccount = await browser.findElement(By.xpath(‘/html/body/div[5]/div[2]/div[2]/div[2]/div/div[3]/div/button[3]’))
await linkSaveccount.click()
await browser.takeScreenshot()

})

We’ve shared both test scripts on Github for your evaluation and comparison.

Overall,  we found the actual response times were quicker in the Classic UI than the Lightning UI. Before jumping to conclusions about the speed of the Classic UI vs. the Lightning UI for human users, we must say that the complexity and features added in this new version are slowing down the script’s speed.  We plan to run some future benchmark tests looking at each transaction separately to parse out more detailed and exact information.

How to use Flood Element to test your own Salesforce instance?

The best way to start scripting in Saleforce.com for testing purposes would be to get your Developers account here. Make sure to include your IP address as Network access to disable the 2FA that may cause your element script to hang up. 

Putting It All Together

When you have your script created, you can upload it into Flood to execute it with 100’s or 1,000’s of concurrent users and try your hand at monitoring your load injectors. The free trial will provide you with enough node hours to execute this test outlined here for 1 hour with roughly 5,000 concurrent users.

If you are load testing using Flood, we’d love to hear from you. Drop us a note and share any ideas that are working for you and feel free to ask our team any of your tough questions!