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 of #IEDriver) 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.
See my tutorial about Protractor.
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.
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.
Same user & same page vs. other fields (title of page, field labels, field values)
Same user but different pages
Adam Sandman https://www.inflectra.com/Rapise/
https://github.com/isalew/selenium-sfdc/blob/master/selenium-sfdc.js Salesforce REST API for Selenium IDE
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
- Import logicline framework to Eclipse IDE
- Add packages Main and script to the project
- Convert the project to testNG format
- Under script package create a new java class and write the steps to automate the testcases
- Under main package create a testNG class and under @test tag create an object of the script and call the function
- After above steps are completed right click on testNG.xml and run as testNG suite
Rajeev Mehta of 3PillarGlobal, in this article explains how he automatically generates access tokens for testing.
By Jitendra Zaa (Salesforce MVP):
- Getting started with Selenium IDE and Salesforce - Part 1 Mar 28, 2015 [11:08] (unfortunately, Selenium IDE is gone)
- Selenium automated testing Part 2
- Performing Load Testing in Salesforce using Selenium and TestNG [3:05] Aug 27, 2017
- Continuous integration in Salesforce Using Jenkins and Git in 20 minutes
https://www.forcetalks.com/blog/salesforce-with-selenium/ by Manglesh Manglesh Sep 14, 2017 provides sample code in video https://automationeasyway.wordpress.com/2017/09/10/automation-testing-setup/
MST Solutions: Automated Salesforce Testing using Selenium Webdriver Dec 29, 2015 [5:48] unrecognizable audio about use of Excel file for data-driven testing is provided at https://www.mstsolutions.com/technical/automated-salesforce-testing-using-selenium-webdriver/
https://bluecanvas.io/2016/12/13/apex-unit-selenium-salesforce.html Use ApexUnit and Selenium to Speed Up Salesforce Development
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
provartesting.com claims to be “The only code-free, integrated automation testing tool for Salesforce.”
https://www.youtube.com/watch?v=n9amswhOxJw Hands-on Training: Write Apex Tests Using Best Practices Dreamforce Video
Udemy class firstname.lastname@example.org
More about Salesforce
This is one of a series about Salesforce
- Salesforce Ohana (about the Salesforce organization and people)
- Salesforce Glossary (of acronyms)
- Salesforce Exhibitors (at Dreamforce)
- Salesforce Onboarding (Trailhead and IDEs)
- Salesforce Offerings (Clouds, Industries, Domains, GitHub, editions, pricing, features, versions)
- Salesforce Certifications (training and exams)
- Salesforce Projects, Superbadges, and Sample Apps
- Salesforce Project Plans
- Salesforce Jobs (within Salesforce, with partners, etc.)
- Salesforce Apps (in AppExchange)
- Salesforce Alexa
- Salesforce Heroku (external apps)
- Salesforce Non-Profit Success Pack
- Salesforce Data Management
- Salesforce Einstein
- 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