Wilson Mar bio photo

Wilson Mar

Hello. Hire me!

Email me Calendar Skype call 310 320-7878

LinkedIn Twitter Gitter Google+ Instagram Youtube

Github Stackoverflow Pinterest

Automate not just testing but also explanations about user state


This article is about the easiest way to automate user clicks and typing on Salesforce Visualforce and Lightning UI. This is for functional testing and for automating work.

Salesforce has built-in “process automation” capabilities such as Validation rules. That’s not what we’re talking about here.

Pretend to be Salesforce Users

Salesforce users have a tremendous need for automation that pretends to be real users (for functional testing) because of the complex security apparatus within Salesforce.

  • Buttons can appear for one user but not another;
  • A user can see a field one day but not another after configurations are changedl;
  • There is two sets of layouts with different UX: a vintage Visualforce and new Lightning;

    CSS IDs in Salesforce are very dynamic. The page layout in Salesforce Visualforce pages are known to change regularly. This challenges script maintenance work in every cycle.

Automated functional verification tools can help testers quickly figure out the various settings affecting whether a given label, control, or data element on the screen either should be or should not be there. In other words, when a “New” button does not appear when it should, the test framework should report more than just “fail”, but (as an admin) look up the various settings that impact visibility (such as User Profile license enablement, Field Level Security, etc.)

People use Selenium for cross-browser testing to ensure that different browsers render correctly.

The SikuliX” build of Selenium includes Google’s OpenCV to work with images captured from the screen. Some add to that Google’s Tesseract to read text in pictures.

Selenium is actually an API. “Selenium scripts” are actually programmed in Java, C#, Python, which each call the Selenium API. In turn, Selenium APIs call a WebDriver program to access the browser DOM IDs and other elements. Each browser requires a different WebDriver program.

JUnit and NUnit libraries are used within Java and C# programming code. Since Java programs use Maven to manage versions.

Selenium Internal to Salesforce

On June 7, 2013, Salesforce employee Jim Evans (@jimevansmusic, a Selenium committer) published this blog saying that “At Salesforce, we use the Selenium open-source project to execute over 40,000 UI-based test cases on our applications as part of our continuous integration build infrastructure.”

At the SeleniumConf Boston 11 June 2013, David Louvton and Amool Gupta presented “Scaling Selenium: The Selenium Infrastructure at Salesforce”.

VIDEO: Selenium at Salesforce Scale Apr 28, 2015 Engineers David Louvton and Sagar Wanaselja show you Salesforce’s best practices and how they automate their Selenium tests at scale. 500 commits per day by 120 teams. No code, just bragging in this video.

GUS (Grand Unified System) is released to Salesforce customers as the Agile Accelerator on AppExchange.

AFAIK code Salesforce uses internally is not open sourced. So each Salesforce user company has to create their own framework for functional testing.


A framework should support priortization of test items so that the highest risk (named “P1”) receive the highest priority (run before those of lowest priority, unless there are technical dependencies). One (of many) ways to classify automation scripts:

a. “Positive Login Happy Path” (the most common paths to get in should just work)
b. “Negative Login Happy Path” (the most common user errors during login should be caught)
c. “Positive Menu Happy Path” (the most common paths through menus should just work)
d. “Negative Menu Happy Path” (the most common user errors menus should be caught)
e. “Positive New User Path” (the most common new user paths should work)
f. “Negative New User Path” (the most common new user user errors should be caught) g. “Positive Retrieval Path” (the most common data retrieval paths should work)
h. “Negative Retrieval Path” (the most common data retrieval user errors should be caught) i. “Positive Deletion Path” (the most common data deletion paths should work)
j. “Negative Deletion Error Path” (the most common data deletion errors should be caught)

Under “Continuous Integration”, Selenium scripts are kicked off by Jenkins when Git makes a push. Some frameworks track the results of each test and automatically put tests on the schedule to make full 24/7 use of test servers.

To enable automation efforts to focus on the user rather than the code, I think the Gherkin language should be used even if you do not use the Cucumber testing tool. It’s a standard way of using regular English sentences to describe what a system should do (its behaviors). Other human languages can be used as well.

Apache “SureFire” generates test reports.

Other aspects of the full workflow include a management system for managing the anomalies and “defects” found.


The “Protractor” build of Selenium adds the capability to test apps built using the Angular framework. (Protractor makes querying for elements much easier by adding accessors to Angular models, bindings, ng-options, and finding elements inside ng-repeat. But many prefer it over Selenium for other apps as well. Protractor adds a convenient waitfor functions and accessors (locators) by button text, partial button text. It enables find by a combination of CSS and text (get me all the divs with class ‘pet’ and text ‘dog’).

Overall, Protractor requires less code than Selenium.

Protractor adds the addLocator function to add custom locators. For example, get elements by handlebars properties.

Page Objects

An effective framework minimizes work by providing a library of “page objects” that replace repetitive test coding with calls to methods within objects.


Wait until page is loaded.

Error messages

Same user & same page vs. other fields (title of page, field labels, field values)

Same user but different pages

Different user

Alternative tools



Adam Sandman https://www.inflectra.com/Rapise/



Isaac Lewis


Logicline Framework

The Test Automation Framework for Salesforce from logicline Germany is built on top of Selenium webdriver and is programmed in the Java language with the TestNG unit test framework accessed from the Eclipse IDE.

https://www.logicline.de/en/blog/2017/06/test-automation-for-salesforce-using-selenium/ A Test Automation Framework for Salesforce by Teny Peter of Logicline, 20. June 2017 is to test the CleverReach app developed by logicline to run on Salesforce. Th app under test integrates mass mailing software with Salesforce. The test scenario creates a mailing campaign of leads and contacts. The created lead and contact are added to the newly created campaign as campaign members. The campaign is then sent to CleverReach for syncing. Afterwards it’s checked if the campaign is successfully created and synched with CleverReach.

The major components of the framework are:

  • Base class: This is a Java class file where all the functions are written. It can be utilized across any script file, thus maintaining the script re-usabilty.

  • Main script runner class is the testing class where it is specified which scripts need to run. Here the precondition and post condition are mentioned.

  • Script classes are classes that extend the base class. It’s where the test steps resides for each test cases. Each and every testcase should be a separate script file which is finally called in the main script file.

  • OR properties is the object repository file where all element identifiers used in the scrips are written. This helps in maintaining the script. If any change happens to the visual-force page that makes changes to the element identifiers, a Test Engineer can change only this one file instead of changing it in the actual script file.

  • Config properties file is a run time configuration file where we can provide all run time configurations like browser type, browser version, username, password and other.

  • TestData.xls: This is an Excel file where all test data used throughout the script are provided. The user can add or modify this Excel file rather than making changes to the script thus helping in improving maintainability.

Steps to Create Script Automation Script

  1. Import logicline framework to Eclipse IDE
  2. Add packages Main and script to the project
  3. Convert the project to testNG format
  4. Under script package create a new java class and write the steps to automate the testcases
  5. Under main package create a testNG class and under @test tag create an object of the script and call the function
  6. After above steps are completed right click on testNG.xml and run as testNG suite

Other testers

Rajeev Mehta of 3PillarGlobal, in this article explains how he automatically generates access tokens for testing.

by Jitendra Zaa (Salesforce MVP)

MST Solutions:


https://www.youtube.com/watch?v=US39w9XwuP4 Test Automation With Cucumber JVM, Selenium, and Mocha Dreamforce Video



https://www.youtube.com/watch?v=YgL0UNVoqQ8 Testing And Debugging Lightning Components Salesforce Developers


https://www.youtube.com/watch?v=HnHwGuO3hVg Lightning Component Testing with Jasmine Salesforce Developers 1.4K views


https://www.youtube.com/watch?v=n9amswhOxJw Hands-on Training: Write Apex Tests Using Best Practices Dreamforce Video

Udemy class appsenseca@gmail.com

More about Salesforce

This is one of a series about Salesforce

  1. Salesforce index

  2. Salesforce Ohana (about the Salesforce organization and people)
  3. Salesforce Glossary (of acronyms)
  4. Salesforce Exhibitors (at Dreamforce)
  5. Salesforce Onboarding (Trailhead and IDEs)
  6. Salesforce Rock Stars (and influencers)

  7. Salesforce Offerings (Clouds, Industries, Domains, GitHub, editions, pricing, features, versions)
  8. Salesforce Certifications (training and exams)
  9. Salesforce Projects, Superbadges, and Sample Apps

  10. Salesforce Project Plans
  11. Salesforce Jobs (within Salesforce, with partners, etc.)

  12. Salesforce Apps (in AppExchange)
  13. Salesforce Alexa
  14. Salesforce Heroku (external apps)
  15. Salesforce DX (Developer eXperience)

  16. Salesforce Non-Profit Success Pack
  17. Salesforce NPSP (Non-Profit Success Pack) performance (with Gatling)

  18. Salesforce Data Management
  19. Salesforce Einstein
  20. Salesforce Selenium (test automation)

Tutorials under construction (listed alphabetically):

  • Salesforce Apex programming
  • Salesforce Apex Testing
  • Salesforce APIs
  • Salesforce Automation
  • Salesforce Bolt
  • Salesforce Customization (objects, fields, page layouts)
  • Salesforce Field Service
  • Salesforce Inbox
  • Salesforce IoT
  • Salesforce Lightning UX
  • Salesforce Mobile
  • Salesforce NPSP (Non-Profit Success Pack)
  • Salesforce Reporting & Analytics (Custom Reports)
  • Salesforce Security
  • Salesforce Selling Success Factors
  • Salesforce Visualforce