Test automation can be tricky, and it’s not unusual for test and quality engineers to struggle with best practices, what tools to use, and updating automation when transitioning to Lightning. This blog post covers UI test automation on Salesforce, highlighting the unique considerations and solutions available for Salesforce testing so that you can make informed decisions about which UI test automation solution is best for your Salesforce organization.
Unique considerations for testing on the Salesforce platform
UI test automation on Salesforce has some unique features for both test creation and test maintenance.
Test creation
In Lightning, we made a conscious decision to hide the identifier of the element. This avoids developers relying directly on implementation details that may evolve over time. While this opacity improves the long-term maintainability of components from a development perspective, it hinders UI test automation, which historically has relied on these types of implementation details to identify visual elements on a page.
In addition, Lightning Web Components also utilizes the Shadow Document Object Model (Shadow DOM) as an isolation mechanism to prevent Components from influencing each other. Shadow DOM boundaries between components break the traditional way of locating page elements.
Test maintenance
Salesforce is committed to continuously improving usability and providing customers with new and more efficient ways to achieve their business goals. In addition, our recent effort to migrate pages from Aura to Lightning Web Components has resulted in a significant change in the underlying structure. A side effect of all these changes is the impact on test maintenance. Because these improvements modify the structure of the Document Object Model (DOM), tests that rely on implementation details in the DOM are often fragile and require constant updates from version to version.
The solution
If you want to automate UI testing on Salesforce, you can use three potential solutions. For each solution, we present the main considerations to keep in mind.
Commercial off-the-shelf products from independent software vendors
Third party paid solutions from the Salesforce ecosystem allow you to build automated UI tests with “clicks instead of code”, which is a great choice for UI test automation. Independent software vendors responsible for these solutions update their toolchains with each Salesforce release to ensure that tests built on their solutions continue to run smoothly. These solutions are best suited to customers with administrative resources who are happy with click-based solutions.
Key considerations
- The customer is responsible for implementing the test suite through the No Code solution.
- Test maintenance costs are lower because vendors are constantly updating their frameworks to abstract out the page changes associated with each Salesforce release.
- The cost of permits can be high
- Tests cannot be easily ported to other testing frameworks (vendor lock-in).
Work with system integrators to build custom test automation infrastructure
If you have minimal internal engineering and management resources and/or existing systems integrator relationships, this solution may be right for you. As part of the Salesforce ecosystem, there are many system integrator partners that offer full-service solutions for customers who do not want to build their own software solutions in-house. For customers who do not have the necessary personnel to build and maintain their own test automation, working with a system integrator to build a custom test automation infrastructure may be the most viable solution. In cases where Salesforce customization is already being performed by system integrators, extending the contract to include UI test automation might be a reasonable strategy.
Key considerations
- A full service solution provided by third party consulting partners.
- System integrator services can be expensive
- For customers already working with a system integrator, the marginal cost of adding UI test automation services may be lower than the cost of establishing a new partnership with the system integrator solely for test automation.
- Ongoing maintenance of the tests by the system integrator may require a separate service contract.
- Depending on the implementation, tests may be ported to other testing frameworks.
Open Source testing framework
Finally, our third and most customized solution is to use an open source testing framework, when the above options are not enough and you have a lot of engineering resources. There are several open source testing frameworks available for UI test automation based on the browser experience. We briefly discuss the most common, but you can explore and use other frameworks.
Core Selenium
Selenium WebDriver is the most popular implementation of the W3C WebDriver specification. Despite its popularity, it provides naked support for test automation and often requires additional accessibility tools to complement its basic functionality. For example, there is no built-in support for Shadow DOM compared to WebdriverIO. Customers looking for Shadow DOM support will need to implement these features themselves.
WebdriverIO
WebdriverIO is a modern, javascript-based, WebDriver spec based testing framework that provides a great deal of functionality that Selenium does not, including Page objects as first-class citizens and Native Shadow DOM traversal. It provides a lot of functionality that Selenium does not, including Page objects as first-class citizens and Native Shadow DOM traversal. However, it still requires substantial and sustained engineering investment.
Key considerations
- The customer is responsible for implementing and maintaining the test infrastructure and test suite through Pro Code technology (engineering resources required).
- Open source frameworks and tools are free
- From an engineering perspective, the ongoing maintenance of test suites is costly.
- Tests can be ported to other testing frameworks with relatively minor changes.
Lessons learned
While there are a number of unique factors to consider in a given Salesforce organization’s UI test automation strategy, there are a number of solutions in the Salesforce ecosystem. Depending on the characteristics of each Salesforce customer, deciding which solution to use is different.
Links and Resources
For those interested in using open source testing frameworks, here are some technical resources to help you overcome some of the unique considerations of testing on the Salesforce platform.
Element identifiers are missing
- Chaining of custom locators
- Use location chains to find child elements
Shadow DOM encapsulation
- WebdriverIO: Shadow DOM support and reusable component objects.
- A guide to handling shaded DOM using Selenium
Changing page structure
- WebdriverIO: Page object mode
- Getting started using the page object pattern in Selenium testing
About the author
Jonathan Au drives large-scale strategic initiatives on The Salesforce platform. He is passionate about the transformative power of technology and is a lifelong learner. You can follow him at Trailblazer.me.