Test automation can be tricky and it’s not unusual for test and quality engineers to struggle with aligning to best practices, what tools to use, and updating automation when transitioning to Lightning. This blog post covers the landscape for UI test automation on Salesforce, with a focus on unique considerations for Salesforce testing and available solutions, so you can make an informed decision on which UI test automation solution works best for your Salesforce org.
Unique Considerations for Testing on Salesforce Platform
UI test automation on Salesforce presents some unique characteristics, both in terms of test creation and test maintenance.
Test Creation
With Lightning, we made a conscious decision to hide identifiers on our elements. This prevents developers from taking a direct dependency on implementation details that may evolve over time. While this opaqueness improves the long-term maintainability of components from a development point of view, it hampers UI test automation, which has historically depended on these types of implementation details to identify visual elements on a page.
Additionally, Lightning Web Components makes use of Shadow Document Object Model (Shadow DOM) as an isolation mechanism to prevent components from affecting one other. The Shadow DOM boundaries between components break traditional means of locating elements on a page.
Test Maintenance
Salesforce works to continuously enhance usability to offer customers new and more efficient ways to accomplish their business objectives. Additionally, our recent efforts to migrate pages from Aura to Lightning Web Components have resulted in significant changes to their underlying structure. One side effect of all these changes is the impact on test maintenance. Because these improvements modify the Document Object Model (DOM) structure, tests that rely on specific implementation details in the DOM tend to be brittle and require continual updates from release to release.
Solutions
If you are looking to automate your UI testing on Salesforce, you have three potential solutions at your disposal. For each solution, we cover key considerations to keep in mind.
Commercial Off-the-Shelf Product from Independent Software Vendor
Third-party paid solutions from the Salesforce ecosystem that allow you to build a suite of automated UI tests through “clicks not code” can be a really great choice for UI test automation. The independent software vendors responsible for these solutions update their toolchain with each and every Salesforce release to ensure that tests built on their solutions continue to run smoothly. These solutions are best for customers with admin resources that are comfortable with click-based solutions.
Key Considerations
- Customer is responsible for implementing test suite through a No Code solution
- Test maintenance costs are reduced, as vendors continually update their frameworks to abstract away page changes associated with each Salesforce release
- Licenses can be costly
- Tests cannot be easily ported to other test frameworks (vendor lock-in)
Working with a System Integrator to Build Custom Test Automation Infrastructure
If you have minimal in-house engineering and admin resources and/or an existing System Integrator relationship, this solution may be for you. As part of the Salesforce ecosystem, there are many system integrator partners that offer full-service solutions to customers not looking to build their own software solutions in-house. Working with a system integrator to build a customized test automation infrastructure may be the most viable solution for customers without the required personnel to build and maintain their own test automation. In situations where Salesforce customizations are already being performed by a system integrator, extending the contract to include UI test automation may be a logical strategy.
Key Considerations
- Full-service solution offered by a third party consulting partner
- System integrator services can be costly
- For customers already partnering with a system integrator, the marginal cost of adding UI test automation services may be less than the cost of establishing a new relationship with a system integrator solely for test automation
- Ongoing maintenance of tests by the system integrator may require a separate service contract
- Depending on the implementation, tests may be portable to other test frameworks
Open Source Test Frameworks
Finally, our third and most custom solution is to use an open source test framework, meant for when the above options aren’t enough and you have many engineering resources. There are multiple open source test frameworks available for UI test automation for browser-based experiences. We briefly discuss the most common, but you can explore and use others.
Core Selenium
Selenium WebDriver is the most popular implementation of the W3C WebDriver specification. Despite its popularity, it offers bare-bones support for test automation and often requires additional helper utilities to supplement its base capabilities. For example, in contrast to WebdriverIO, it does not have built-in support for Shadow DOM. Customers looking for Shadow DOM support need to implement these capabilities on their own.
WebdriverIO
WebdriverIO is a modern, JavaScript-based test framework based on the WebDriver specification. It provides a great deal of functionality that is not available in Selenium, including Page objects as first-class citizens and Native Shadow DOM traversal. However, it still requires a significant and ongoing engineering investment.
Key Considerations
- Customer is responsible for implementing and maintaining the test infrastructure and test suite through Pro Code technologies (engineering resources are required)
- Open source frameworks and tools are free
- Ongoing maintenance of test suite can be costly from an engineering standpoint
- Tests are portable to other test frameworks with relatively minor modifications
Takeaways
While there are multiple unique factors that need to be considered in the UI test automation strategy for a given Salesforce org, there are plenty of solutions available in the Salesforce ecosystem. The decision on which solution to use varies based on the characteristics of each Salesforce customer.
Links & Resources
For those of you who are interested in using open source test frameworks, here are some technical resources that will help you to overcome some of the unique considerations with testing on the Salesforce Platform.
Lack of Element Identifiers
Shadow DOM Encapsulation
- WebdriverIO: Shadow DOM Support & Reusable Component Objects
- A Guide to Working with Shadow DOM using Selenium
Constantly Changing Page Structures
About Me
Jonathan Au drives various large-scale strategic initiatives that span the Salesforce Platform. He is passionate about the transformative power of technology and is a lifelong learner. You can follow him on Trailblazer.me.