Automation Testing in Salesforce – Design Keys

This blog is part two in a series on automation testing in Salesforce. For part one, with a breakdown of the unique challenges of Salesforce and an explanation of available testing tools, click here.

One common misconception around automation testing is that it encompasses only mild scripting, with no serious thought needed towards solution design or coding practices. This is a very dangerous misconception, as neglecting key design considerations will leave an automation suite brittle, overly complex, and unreliable. Instead, automation testers should be enabled as full developers, with proper care given to training and code design. When testers combine this training with a technical understanding of Salesforce, it helps tremendously in creating a test suite that is both portable and efficient.

Portable

A common limitation of test suites is that they can’t easily be ported between environments. Test users must be manually configured, test data created, and URLs hard-wired. Because Salesforce sandboxes can be spun up on-demand, an inflexible automation suite can severely limit your team’s ability to pivot with changes to the pipeline. When designing a test suite, testers should instead work closely with developers and architects to articulate the test data needs.

With this knowledge, developers and testers should cooperate to configure their Salesforce instances with test data on the creation of a new sandbox, as well as designing the tests as data-agnostic as possible. Not relying on previously created data is a specific benefit of testing in Apex test classes, and adopting that approach across all your tools allows you to use the same tests on many non-prod environments, and easily encompass new environments as needed.

Efficient

Salesforce workflows can be long, and often have complex custom business functionality shoehorned in the middle of an otherwise out-of-the-box feature. If a tester has no understanding of the underlying data, they are forced to create UI tests that walk through entire workflows just to test a few custom steps at the end. This leads to unnecessarily long-running and risky suites that obfuscate the original purpose of the test. Instead, testers should engage developers to understand the underlying data state of the feature. Rather than replicating that data state through manual workflows, they should cooperate to build tools to create that data state instantly, and then run a short, focused UI test on that new data.

The most powerful of these tools is the Salesforce REST API, mentioned earlier. With a few simple configurations, you can give your automation code access to the full functionality of this API. Using established REST protocols, you can create objects in specific states directly through the service calls. Over time, a robust data factory can be built with the functionality to create on-demand data at test run-time. When a test navigates to this data object, you will have confidence you are hitting fresh, reliable data in the exact right spot.

Let’s build out a simple example. Let’s say you have an Opportunity object with a three-step workflow. On step three, there is a complicated digital form that needs to be tested in a few different ways. Instead of creating an Opportunity, completing step one, completing step two, and then testing the form functionality, create an Opportunity already completed through step two using the Salesforce API. Then, the UI can load that specific Opportunity object and test the form right away.

Modular

As a final test design tip, strive to make scripts as generic and reusable as possible. Salesforce is highly modular, with common design elements and components being used consistently throughout the platform. Because of this, an automation tester has the unique opportunity to write very modular code, which can speed up future test development tremendously.

There are two rough categories of common code you can utilize when scripting Salesforce automation tests. The first is a set of common functions for handling low-level actions like clicking buttons or selecting dropdowns. A major challenge of the Salesforce UI is the lack of easily identifiable ids or element selectors. Solve for these challenges once, then make the solution available to the rest of the suite. In the same way, if you are running into a UI glitch within Salesforce, solve for it once, then integrate that solution into all other testing code.

The second layer of common code should be organized around specific Salesforce components, like the various flavors of edit screens and pop-ups. Because of their render time, visual loading indications, and element overlays, these edit components can be quite tricky to test. Create a common code for handling these complex components as soon as possible, and reuse the code moving forward. This will improve both the reliability and readability of your scripts and make it much easier for folks to come behind and follow your test design. A final benefit of this modular approach is a quick turn-around when Salesforce releases new versions of their software, allowing you to make minimal adjustments as the underlying UI layout changes.

Testing is A Go

At the beginning of this blog series we posed the question: “Is automation testing in Salesforce worth the effort?” The answer is absolutely yes, provided you take the right approach. Take the forethought to start with appropriate Apex test classes, and make sure you avoid bloating your UI suite with low value, unstable tests. Promote cooperation between developers and testers to ensure test suites can be ported between environments and are as focused and efficient as possible. Employ modular design patterns into your testing scripts, solving the hard problems once and then reusing them as your project picks up speed. As you integrate these approaches into your testing strategy, the stability of the suite will increase, the runtime will go down, and you’ll be delivering tested features in proper rhythm with your hard-working Salesforce admins. Happy scripting!

Separately, we currently have job listings for Salesforce developers. If you are interested in seeing what's available, come check out our open positions here.