Simply simplifying SalesforceDX test automation might seem a bit daunting because of the different nature of scratch orgs. Salesforce defines a scratch org as a ‘dedicated, configurable and short-term Salesforce environment that you can quickly spin up when starting a new project, a new feature branch or a feature test.’ They are short-lived, created and deleted as needed, and relatively speaking (compared to sandboxes and production orgs), there are many. Without some planning and organization, keeping track of scratch orgs, connections, and tests can be a problem in a hurry. This is where Provar and ProvarDXTM can help. 

Note: If you’re new to ProvarDXTM, the simplest explanation is that ProvarDXTM makes it incredibly easy to run Provar tests in Salesforce DX. For more background, check out the first ProvarDXTM blog or the ProvarDXTM product page on the website.

Why We Love Provar Reason # 237: Managing Salesforce Connections


One of the things that customers love about Provar is how simple it is to set up and manage Salesforce connections. Build it once and use it for as many tests as you need. With environments, it’s crazy simple to switch from one link to another. Suppose you have worked with something other than Provar and had to build a lot of tests that include ‘click the login button, type username, type password’ test steps or had to remember five different username and password combinations to run tests in your favorite sandbox or dev org. In that case, you know that having pre-built reusable connections is a big deal.

What About Scratch Orgs?

Because of their temporary nature and because there are more of them to manage, connection management for scratch orgs can be a challenge. Fortunately, simplifying SalesforceDX test automation helps make it easy to create aliases for scratch orgs. ProvarDXTM can take advantage of connection overrides to build a test suite for scratch orgs that is very simple to maintain.

5 Steps Of Setting Up Provar Tests For Scratch Orgs In Salesforce DX.

Step 1: Aliases


When you create a scratch org, Salesforce assigns a username as a generic email address. To keep track of what the org is for, it’s good practice to define a naming convention that you (and your team) can remember and assign an alias when you create the org. Something like:

$ sfdx force:org: create -s -f config/project-scratch-def.json -a Admintest-org

With a result similar to the following:

aliases in setting up Provar tests for scratch orgs In Salesforce DX.

Instead of usernames like test-kzar1majz3jf@example.com and test-qtgqiuvnmlpn@example.com, you can use easy-to-remember (and understand) aliases like Admintest-org and Salestest-org. 

Here’s an example:

sample easy to remember username in test

Step 2: Making Provar Tests Available for Scratch orgs – Creating a provardx-properties.json File


Setting up Provar tests for use in Salesforce DX is straightforward.

From Provar Desktop, select the tests you want to use. Then right-click and choose Export to ProvarDX from the drop-down menu.

In the screenshot below, we’ve selected the tests from Lessons 1, 2, 3, and 4 to export. 

screenshot of exporting to provar dx

You can either a) save the file and access it from Visual Studio or b) copy the file to your clipboard and paste it into a file you create in Visual Studio.

provardx visual studio

The export process will create a provardx-properties.json file, which Salesforce DX uses to execute the Provar tests.

export process will create a provardx-properties.json file for Simplifying SalesforceDX Test Automation

For more on the ProvarDXTM property file, check out the ProvarDXTM technical product overview (scroll to the bottom of the web page to find the overview). 

Step 3: Adding Connection Overrides to the provardx-properties.json file


The property file you imported includes the original connections set up when you created the tests in Provar Desktop. To run those tests against a scratch org, use connection override. It’s important to note that the connection overrides are not included in the property file by default and must be added after it’s created. But ProvarDXTM recognizes Salesforce aliases, so you can add the connection overrides once you’re done! If your original tests have different links for testing multiple profiles, use connection overrides for each user profile you want to try in the scratch org. 

Our original test environment has connections for two profiles, Admin and Sales.

sample test environment for Sales and Admin in Simplifying SalesforceDX Test Automation

We want to be able to test both of those profiles in our scratch org, so we set up an override connection for each. Here are two options – the first using aliases (preferred/simpler) and the second with usernames.

Alias:

test profile in scratch orgs using aliases to simplify SalesforceDX test Automation

Username:

test profile in scratch orgs using usernames to simplify SalesforceDX test Automation

Step 4: Setting Up for Simple Reuse and Minimal Maintenance


Set up your ProvarDXTM property file with an alias you can use for any scratch org you want to test, plus the connection overrides. You won’t have to change the property file unless you want to change the specific tests or execution settings (under the environment section in the properties file – browser, test environment, etc.). You can use the property file to execute any test in that Provar workspace. 

Step 5: Try ProvarDXTM (it’s effortless)


Starting from scratch (pun intended) on a new MacBook Pro, I built the setup for these blog screenshots in a few hours. If you’re already working with Provar and Salesforce DX, you could have everything ready in less than an hour. It’s that simple. For all of the benefits of simplifying scratch org testing and adding testing earlier in the application lifecycle, ProvarDXTM is a slam dunk.

This blog is a quick summary of simplifying SalesforceDX test automation, hopefully encouraging you to check out ProvarDXTM. As you would expect from Provar, there are plenty of ways to optimize ProvarDXTM once you’ve got the basic setup. Caching metadata for faster execution and pre-compiling page objects are two examples. For details, please take a look at this documentation

For more information, check out www.provartesting.com/provardx.