Automate User Interface Testing – Lightning & Classic

Blog:

Testing updates to a database is easy, but testing the user’s screen efficiently is a whole other ball game. When I was first being indoctrinated into the world of Salesforce development, User Interface (UI) testing wasn’t even mentioned. Everything was centered around ensuring Salesforce’s minimum 75% coverage was met. I still don’t see as much focus on it as I’d like in community discussions. Part of it may be due to misunderstanding the benefit, another would be lack of known online resources, and the remaining seems to be lack of internal resources to dedicate efforts.  

My research for this was more focused on the admins of organizations but also can benefit developers looking to add stability to their org. This does not assist in Apex Code Coverage requirements but provides an extra layer of safety to your org before pushing out enhancements or upgrading managed packages. If you have the bandwidth, or an extra admin who is looking to run hybrid between administrative work and QA testing, this would be a great way to save hours in the long run. 

This sort of technology isn’t new. In fact, many of my friends/colleagues who specialized in web development mentioned using this from time to time. Now you can get your hands dirty by learning a whole computer language plus an API library and spend dozens of hours developing this from scratch. While everyone was partying, I made the cool-guy decision to spend a couple weekends teaching myself Python and then Selenium’s Webdriver package to do web scraping; however, I’m going to show you something that’s free and how to easily automate your user tests.  

Before I begin showing the technology, I wanted to clarify the situations and show examples of what this would solve. The topics are (1) user personas, (2) enhancement/regression testing, and (3) package testing. 

User personas is the simplest out of the three. A user persona is defined by Wikipedia as “…  a fictional character created to represent a user type that might use a site, brand, or product in a similar way.” For example, you may hear stories of “John Smith is a cashier at Cloud Computers and is wanting to provide a refund to a customer but doesn’t know how.” Let’s break that down in a different way to point out the key aspects here. 

• Generic USA name: John Smith 
• Role: Cashier 
• Business/Department: Cloud Computers 
• Action: Provide refund to a client 

You would then start to plot out how John Smith would accomplish this task. You would list out steps in successive order that are repeatable and predictable for everything the employee will encounter in their daily work lives. Once done, you would repeat this process for all colleagues until you’ve covered every known situation. 

The second item is enhancement/regression testing. On top of developing new changes or fixing bugs, the worst thing a developer can do is introduce new issues in the same update. I’ve done it. If you’re a developer, you’ve probably done it. The best developers in the industry have done it at least a handful of times. It’s all part of the learning process. However, to keep company morale and user adoption high, this must be reduced to the absolute minimum without sacrificing new enhancement efforts.  

For example, think of yourself in the real estate industry and as a user at a fictious company called Universal Realty. You heard the in-house developer just built out a new tool to make researching properties a breeze. It does a whole slew of things and is boasted from management as a game changer. You start to use it and realize it’s updating Accounts in your Salesforce database in strange and unintended ways. Your whole routine is centered around Accounts being up-to-date and accurate. However, this new software is causing tandem automation to fire when the developer didn’t intend it and messing up the data in ways where it’s difficult to repair. In situations like this, UI tests thoroughly verifying the system before publication would prevent lack of faith from your user-base. 

Lastly, and what I consider the most powerful, managed package testing. I recall many situations where clients would dedicate two to ten people from varying departments in the company to test package upgrades a couple weeks each year to keep up on versions. That adds up both costs and dread quickly from volunteered users. If used correctly, the type of testing I’m going to demonstrate farther down this article will let you test most packages without writing any code. 

After a lot of research, we’re using Katalon’s Chrome Extension Katalon Recorder for a handful of reasons: it’s free, simple to use, and is backward compatible with popular languages like Python and Selenium. On the export function, it provides working code of what your point-and-click steps are doing. You save all your steps in an HTML file…which can be easily versioned in a Git resource like Github or Bitbucket. I did find the Ghost Inspector Chrome Extension, but the price tag starting at $89/month wasn’t appealing. It does seem more suited for large efforts and more of a “white glove” software in comparison, but I prefer free software that does the same core concept. 

Using Katalon is almost as simple as point-and-click testing. They provide a nice tutorial and walkthrough of the suite’s capabilities on their website. While the video shows the presenter using a Mac, it does work the same way for Windows. I recommend reviewing the link and any other tutorial videos made by them to get acquainted with the software.  

Now we’re able to look at how to test in Salesforce, whether it’s in Lightning or Classic. Testing isn’t much different than what you saw in the tutorial video above. The only issue is how Salesforce Lightning makes every input field so dynamic that you must tweak your recordings ever so slightly. I’m going to show the exact same recording in Lightning and Classic which can be found here if you want to import them for your own testing. The URLs will be specific to my instance, but the rest of the references should work roughly the same. Admittedly, it’s more straightforward with Classic than Lightning. 

Creating Account in Classic 

Creating Account in Lightning 

The main reason why I had to readjust so many of the “Target” values has to do with Lightning’s dynamic architecture. If you see a reference to an “Id=”, then it needs to be readjusted to a different XPath. IDs in a webpage must be unique, and Salesforce likes to make them unique with almost every page load. To combat this, choosing the XPath, which looks like its traversing the DIVs and other elements, is advised. The dropdown can show you your options. It is recommended to test your steps a few times prior to saving them. 

It should be noted that I’ve seen this software get a little buggy in Lightning due to how fast it operates. For instance, it may suddenly stop with a red line saying, “Element X not found.” I noticed retrying the failed class once more tends to fix it. If it continues to fail, then the problem needs to be investigated. You can adjust the speed, but I didn’t see it improve the testing performance by much. Retesting is the surefire way or ensuring things are properly working. 

Voila! You have everything you need to start recording, testing, and versioning. We use it in a variety of ways. As a system administrator, I’m able to log in as other users in the sandbox prior to running these tests. This saves time in coordinating efforts with another individual on something which a robot could test for you. Happy testing!